MODÜL 0 — Etik ve Yasal Çerçeve

Bu modül, orta/ileri seviye network güvenliği çalışmalarını “teknik yapılabilirlik”ten çıkarıp profesyonel, denetlenebilir ve zarar vermeyen bir zemine oturtur. Ağ güvenliği denetimleri; yazılı yetki, açık kapsam, operasyon kuralları (RoE), risk/yoğunluk limitleri, veri minimizasyonu ve kanıt bütünlüğü yoksa teknik olarak doğru görünse bile hukuki/etik/operasyonel hata üretir. Bu yüzden odak, “ne yapabilirim?” değil; “ne yapmalıyım ve neyi asla yapmamalıyım?” refleksidir. Modül ayrıca raporlama çıktını Bulgu → Etki → Öneri → Kanıt (rapor formatı) standardına taşır: kanıt–yorum ayrımını korur, belirsizliği dürüstçe yönetir ve izlenebilir süreç izi bırakır. Sonuçta, herhangi bir çalışmaya başlamadan önce RoE + Do Not Harm planını yazıp uygulayabilecek; veri/kanıt disiplinini teknik adımların önüne koyabileceksin. Bu modül “gating”tir: doğru geçilmezse sonraki modüller uygulanmaz.

Profesyonel ağ çalışması

Tarama ve doğrulama adımlarından önce bu üç soruya cevap yazın.

Yazılı yetki

IP aralığı ve yöntem sınıfı imzalı belgede değilse varsayılan cevap “hayır”dır.

Yoğunluk & durdurma

Rate limit, pencere, stop condition. Üretim veya paylaşımlı ortamda “bir tur daha” çoğu zaman ihlal riskidir.

Kanıt & veri

Paket yakalama ve loglarda PII minimizasyonu; hash + metadata ile yetinme kararı.

Etik ve yasal çerçeve: yazılı yetki, kapsam ve denetlenebilirlik.

Bu Dersin Hedefleri

Yetkilendirme kültürünü oturtmak: Yazılı izin + RoE + kapsam/kapsam dışı çerçevesini operasyonel hale getirmek.
Risk yönetimini sayısal limitler, stop condition ve kill-switch ile uygulanabilir kılmak.
Veri korumada veri minimizasyonu kararını netleştirip, kanıt bütünlüğünü hash + saklama + erişim kayıtları + zincir (chain of custody) ile güvenceye almak.
Bulguları karar vericiye taşıyacak şekilde Bulgu → Etki → Öneri → Kanıt (rapor formatı) standardında raporlamak.
“Bypass/erişim” kavramlarını yalnız farkındalık düzeyinde (kategori→amaç→iz/sinyal→kontrol→kanıt örneği) ele alıp suistimal üretmemek.
Komut ve araç kullanımını denetim–doğrulama–kanıt sınırında tutarak güvenli çalışma standardı oluşturmak.

0.1 Yetkili çalışma ilkeleri

Yetkili çalışma, “teknik olarak yapabiliyorum” yaklaşımı değil; “yazılı olarak izin verilen sınırlar içinde çalışıyorum” disiplinidir. Yazılı yetki (written authorization) hukuki zemini kurar; RoE (Rules of Engagement) ise operasyonun kurallarını netleştirir: kim çalışır, ne zaman çalışır, hangi yöntemler serbesttir, hangi adımda durulur ve acil durumda kim bilgilendirilir.

Kapsam (in-scope) ve kapsam dışı (out-of-scope) alanlar somut, ölçülebilir ve denetlenebilir şekilde yazılmalıdır:

Kapsam Öğesi	Not
IP aralıkları	Yalnız dokümantasyon bloklarıyla örneklenir.
DNS adları	Yalnız example.* formatında yazılır.
Cloud proje/hesap kimlikleri	Kurum tarafındaki yetki ve sahiplik net tanımlanır.
SSID ve yönetim arayüzleri	Kritik erişim noktaları ayrıca belirtilir.

Unutma: “izin var” ifadesi, sınırsız işlem hakkı vermez. Platform şartları, hız/yoğunluk limitleri ve yöntem sınırları yetkinin ayrılmaz parçasıdır.

Etki / risk

Yazılı izin veya RoE yoksa, en basit doğrulama adımı bile yetkisiz işlem sayılabilir; hukuki ve kurumsal yaptırım riski oluşur.
Belirsiz kapsam “scope creep” üretir; kritik sistemlere istemsiz temas, kesinti ve itibar kaybı riski artar.
Platform şartları ve hız limitlerinin ihlali; hesap kısıtı, engelleme, veri kaybı ve operasyonun yarım kalmasıyla sonuçlanabilir.

Tespit sinyali / kanıt

İmzalı/onaylı yetki belgesi ve RoE dokümanı (tarih, sürüm, onaylayanlar).
Kapsam/kapsam dışı listeleri (IP, DNS, SSID, cloud kimlikleri).
Deconfliction kayıtları: bilgilendirilen ekipler, zaman penceresi, acil durdurma irtibatı.

Savunma kontrolü / düzeltme yaklaşımı

Standart RoE şablonu kullan: kapsam, yöntem sınırları, zaman penceresi, stop condition, kill-switch, veri minimizasyonu ve rapor formatı net olsun.
Kapsam taşmasını önlemek için “iş öncesi kontrol noktası” uygula: ilk adımda sadece düşük riskli okuma/doğrulama yap; anormallikte hemen dur.
RoE’yi tek seferlik belge değil, paydaşlarla paylaşılan ve sürümlenen yaşayan bir operasyon kılavuzu olarak yönet.

Dikkat: Sözlü onay veya “mesajdan anladım” ifadesi profesyonel ortamda yetki yerine geçmez. Yazılı izin + RoE + net kapsam yoksa çalışma başlamaz.

İpucu: Kapsamı sadece “IP bloğu” olarak bırakma; VPN uçları, yönetim arayüzleri, DNS zone’ları ve cloud proje/hesap kimliklerini ayrıca tanımla.

0.2 Risk yönetimi

Risk yönetimi: limitler, stop condition ve kill-switch ile kontrollü operasyon.

Operasyonel risk seviyesi (anlık izleme)

Risk yönetimi; çalışmanın yoğunluğunu, etkisini ve geri dönüşünü kontrol ederek “Do Not Harm” ilkesini pratikleştirmektir. Bu; sayısal hız/yoğunluk limitleri, süre sınırları, stop condition (dur koşulları) ve kill-switch (acil durdurma) ile yapılır. Amaç “risk yok” demek değil; riskin ölçülü, izlenebilir ve geri alınabilir olmasıdır.

Etki / risk

Kontrolsüz yoğunluk; servislerde yavaşlama/kesinti, log altyapısında taşma ve alarm fırtınası doğurabilir.
Kill-switch yoksa küçük bir sorun büyür; containment kararları gecikir.
Stop condition tanımsızsa ekip kriz anında “devam mı dur mu?” ikileminde dağılır.

Tespit sinyali / kanıt

Hizmet sağlığı göstergeleri: yanıt süreleri, hata oranı artışı, bağlantı sayısı, log ingest hızındaki ani artış (yalnız kurum içi yetkili görünürlük)
Zaman çizelgesi: başlangıç/bitiş, kontrol noktaları, durdurma anları
Değişiklik kayıtları: limitlerin kim tarafından, hangi gerekçeyle belirlendiği

Savunma kontrolü / düzeltme yaklaşımı

“Düşük riskli doğrulama”yı standart yap: kısa süre, tekil hedef/servis, minimum yoğunluk, kısa zaman penceresi.
Kill-switch’i operasyonel hale getir: kim tetikler, hangi kanaldan haber verir, hangi adım “durdurma” sayılır.
Stop condition’ları ölçülebilir yaz: örn. belirli süre boyunca gecikme artışı, hata oranı eşiği, log ingest anormalliği, kullanıcı şikâyeti.

Dikkat: Risk yönetimi “teknik ekibin keyfi” değildir; RoE’nin ayrılmaz parçasıdır. Limit yoksa teknik doğruluk, operasyonel zararı telafi etmez.

İpucu: Her limitin arkasına gerekçe yaz: “hangi zararı önlüyor, hangi kararı hızlandırıyor?”

0.3 Veri koruma ve kanıt bütünlüğü

Hash + manifest + erişim kaydı = denetlenebilir kanıt zinciri

evidence-check.sh — veri koruma kontrol akışı (kavramsal)

analist@sebs:~$ date -Iseconds 2026-04-16T14:25:33+03:00 analist@sebs:~$ sha256sum evidence.pcap 8f4...b91 evidence.pcap analist@sebs:~$ printf "evidence.pcap | SHA-256 | 2026-04-16T14:25:33+03:00" >> manifest.txt analist@sebs:~$ getfacl Evidence/ | head -n 8 # owner: sec-team # group: incident-response user::rwx group::r-x other::--- # Amaç: kanıt bütünlüğü + erişim denetimi + zaman tutarlılığı

Veri koruma; gereksiz veri toplamamak (veri minimizasyonu), saklama süresini (retention) disipline etmek, erişimi kayıt altına almak ve kanıtı değişmez kılmak (hash + chain of custody) demektir. Kanıt; log satırı, flow özeti, PCAP kesiti, ekran görüntüsü, kural/politika export’u olabilir. Kritik olan; kanıtın ne zaman, kim tarafından, nereden alındığının ve sonradan değişmediğinin gösterilebilmesidir.

Etki / risk

Fazla veri toplamak gizlilik ihlali riskini büyütür; kurum içi ve sözleşmesel yük doğurur.
Kanıt bütünlüğü zayıfsa rapor “iddia” gibi kalır; denetimde savunulamaz.
Retention yanlış yönetilirse ya kanıt erken silinir ya da gereksiz veri birikerek güvenlik ve maliyet riski doğurur.

Tespit sinyali / kanıt

Hash kayıtları (ör. SHA-256), manifest (dosya adı, boyut, hash, zaman damgası)
Erişim kayıtları: kim aldı, kim görüntüledi, kim kopyaladı
Zincir formu: teslim–tesellüm, saklama yeri, erişim yetkisi

Savunma kontrolü / düzeltme yaklaşımı

Veri minimizasyonunu karar haline getir: “Bu soruyu cevaplamak için en az hangi veri yeterli?”
PCAP gerekiyorsa “tam yakalama” yerine kesit yaklaşımı: süre/host/port ile daralt, gereksiz içerik riskini azalt.
Kanıt paketleme standardı uygula: tek klasör yapısı + manifest + hash + erişim notu + saklama disiplini.

Dikkat: Kanıt ile yorum aynı şey değildir. Kanıt ham veri/çıktıdır; yorum çıkarımdır. Raporun güvenilirliği bu ayrımda yaşar.

İpucu: Dosya adlandırmayı standartlaştır: YYYYMMDD_HHMM_kaynak_tur_kisa-aciklama.ext ve her dosya için hash’i manifest’e yaz.

0.4 Raporlama standartları

Rapor: teknik çıktıyı karar verilebilir hale getirir.
Omurga:Bulgu → Etki → Öneri → Kanıt akışı, raporun denetlenebilir ve karar odaklı olmasını sağlar.

Bulgu

Etki

Öneri

Kanıt

Bulguda “ne gördüm?”, etkide “neden önemli?”, öneride “ne yapılmalı ve nasıl doğrulanmalı?”, kanıtta “hangi veri bunu destekliyor?” net olmalıdır. Yönetici özeti (risk/iş etkisi) ve teknik ek (kanıt/çıktı/konfig farkı) ayrıştırılır.

Etki / risk

Kanıtsız bulgu uygulanmaz, tartışmada kaybolur.
Aşırı teknik rapor karar vericiyi kaybettirir; aşırı yüzeysel rapor uygulayıcıyı.
Etik sınırlar (limitler, kapsam) raporda görünmezse, denetimde “kurallara uyuldu mu?” sorusu cevapsız kalır.

Tespit sinyali / kanıt

Ek referansları: “Ek-1: politika export”, “Ek-2: log kesiti”, “Ek-3: zaman senkron doğrulama çıktısı”
Zaman çizelgesi: bulgunun görüldüğü aralık
Belirsizlik notu: eksik veri varsa “hangi veri yok, bu neyi etkiler?”

Savunma kontrolü / düzeltme yaklaşımı

Her bulguya “karşı kanıt” sorusu ekle: “Bunu ne çürütür?”
Öneriyi doğrulanabilir yaz: “değişiklik sonrası hangi çıktı ile doğrulayacağız?”
Etik uyarı okuryazarlığını rapora entegre et: kapsam/limit uyumu, stop condition tetiklenmediyse bile “izlendi” kaydı.

Dikkat: Kanıt yokken “kesin saldırı var” gibi kesin ifadeler raporu zayıflatır. “Gözlenen sinyaller şunu düşündürüyor; şu kanıtla doğrulanmalı” dili daha denetlenebilirdir.

İpucu: Teknik ekte ham çıktıyı tek başına bırakma; kritik alanları işaretle ve “neden önemli?” notu ekle.

0.5 HOW-TO: RoE + “Do Not Harm” Uygulama Planı

Aşağıdaki çıktı, operasyon öncesi doldurulacak runbook/checklist olarak tasarlanmıştır.

Hazırlık

Uygulama

Doğrulama

Kanıt

Rollback

Faz	Odak	Beklenen Çıktı
Hazırlık	Kapsam, limitler, kill-switch, veri minimizasyonu	Onaylı RoE + net sınırlar
Uygulama	Düşük riskli başlangıç ve sınırların korunması	Zaman damgalı adım kayıtları
Doğrulama	Karşı kanıt ve çapraz kontrol	Doğrulanan/çürütülen hipotezler
Kanıt Paketleme	Manifest, hash, erişim kaydı	Denetlenebilir kanıt seti
Geri Dönüş	Eşik temelli rollback planı	Kontrollü geri alma + doğrulama

Hazırlık

1.Kapsam/kapsam dışı yazılılaştır

İzinli IP aralığı örneği: 192.0.2.10–192.0.2.20
Kapsam dışı örneği: 192.0.2.1 (gateway), 198.51.100.5 (yedek sistem)
İzinli DNS örneği: vpn.example.com, mgmt.example.com
İzinli zaman penceresi: (örn.) hafta içi belirli saat aralığı
Yasak yöntem sınıfları: (örn.) hizmet kesintisi riski taşıyan yük denemeleri, sosyal mühendislik vb. (RoE’de açık yazılır)

2.Trafik/yoğunluk limitleri + stop condition + kill-switch

Yoğunluk/süre limitleri (sayısal)
Stop condition: gecikme artışı, hata oranı, log ingest anomalisı, kullanıcı şikâyeti vb.
Kill-switch: tetikleyici kişi(ler), iletişim kanalı, “durdurma” sayılan aksiyon

3.Veri minimizasyonu kararı

Hedef sorular: “hangi iddiayı doğruluyoruz?”
Minimum veri: hangi log/flow/PCAP kesiti yeterli?
Retention: saklama süresi ve erişim yetkileri
Kanıt paketi standardı: manifest + hash + erişim kaydı + saklama

Uygulama

4.Kontrollü başlat

İlk 10–15 dk yalnız denetim/okuma ve düşük riskli doğrulama
Zaman damgası ile adım adım kayıt tut

5.Sınırları uygula

Limit yaklaşımında “yavaşlat/durdur”
Kapsam dışı sinyal görülürse hemen dur ve deconfliction kanalını çalıştır

Doğrulama

6.Karşı kanıt ara

Bulguyu yanlışlayabilecek veriyi özellikle kontrol et
Kaynakları çapraz doğrula (ör. politika değişikliği kaydı ↔ ilgili zaman aralığı logları ↔ hizmet metrikleri)

Kanıt paketleme

7.Kanıt dosyalarını paketle

Dosya yapısı + manifest (dosya adı/boyut/hash/zaman)
Hash üret + erişim kaydı + zincir notu
Minimizasyon gerekçesini rapor ekinde belirt

Geri dönüş / rollback

8.Geri dönüş planı

Hangi eşiğe gelince geri dönülecek?
Kim uygular, ne doğrulanır?
Geri dönüş sonrası doğrulama çıktısı (kanıt) planı

0.6 Komut & Araç Okuryazarlığı (Denetim / Doğrulama / Kanıt)

Aşağıdaki komutlar saldırı amaçlı değildir; yalnızca zaman senkronu, kayıt disiplini, bütünlük ve erişim kontrolü için örneklenmiştir.

Zaman

Komut

Hash

Manifest

Erişim

Platform	Odak	Örnek Çıktı
Windows	Zaman/NTP, hash, ACL, event export	Tarih-saat metni + SHA-256 + ACL listesi
Linux	UTC/NTP, hash manifest, ACL kontrolü	ISO-8601 zaman + manifest.sha256
macOS	UTC, time server, izin/log kesiti	UTC timestamp + DNS/log kesiti + hash

Windows (PowerShell / CLI)

1.Get-Date -Format "yyyy-MM-dd HH:mm:ss.fff K"

Amaç: Kanıt notlarıyla tutarlı zaman damgası üretmek
Beklenen çıktı türü: Tarih/saat metni (timezone dahil)
Yorum ipucu: Zaman dilimi farkları korelasyonu bozar; raporda tek format kullan
Güvenli sınır: Okuma

2.w32tm /query /status

Amaç: Zaman senkronunun (NTP) durumunu doğrulamak
Beklenen çıktı türü: Kaynak (Source), son senkron zamanı, durum metni
Yorum ipucu: “Source” beklenen kurumsal zaman kaynağı mı? “Last Sync” güncel mi?
Güvenli sınır: Okuma

3.Get-FileHash .\evidence.pcap -Algorithm SHA256

Amaç: Kanıt dosyasının bütünlüğünü hash ile sabitlemek
Beklenen çıktı türü: Hash değeri + algoritma + dosya yolu
Yorum ipucu: Hash’i manifest’e yaz; dosya taşınırsa yeniden doğrula
Güvenli sınır: Okuma/kanıt üretimi

4.icacls .\Evidence /T

Amaç: Kanıt klasörü erişim izinlerini denetlemek (yetkisiz erişim riskini azaltmak)
Beklenen çıktı türü: ACL listesi (kullanıcı/grup izinleri)
Yorum ipucu: “Everyone” gibi geniş izinler kanıt zincirini zayıflatır
Güvenli sınır: Okuma

5.wevtutil epl Security .\Security.evtx

Amaç: Olay kayıtlarını kanıt olarak dışa aktarmak (minimizasyon: gerekliyse ve zaman penceresiyle)
Beklenen çıktı türü: .evtx dosyası
Yorum ipucu: Export sonrası hash al; erişim kaydını ekle
Güvenli sınır: Çıktı üretimi (sistem davranışını değiştirmez)

Linux

1.date -Iseconds

Amaç: ISO zaman damgası standardı oluşturmak
Beklenen çıktı türü: ISO-8601 tarih/saat metni
Yorum ipucu: Teknik eklerde aynı formatı kullan; karışıklığı azalt
Güvenli sınır: Okuma

2.timedatectl status

Amaç: NTP/saat senkronunu doğrulamak
Beklenen çıktı türü: Senkron durumu ve zaman ayarları
Yorum ipucu: “System clock synchronized” beklenen durumda mı?
Güvenli sınır: Okuma

3.sha256sum evidence.pcap | tee evidence.pcap.sha256

Amaç: Hash üretip kayıt altına almak
Beklenen çıktı türü: Hash satırı + .sha256 dosyası
Yorum ipucu: Manifest’e ekle; doğrulama gerektiğinde bu dosyayı referans al
Güvenli sınır: Okuma/kanıt üretimi

4.getfacl Evidence/

Amaç: Kanıt klasörü ACL’lerini denetlemek
Beklenen çıktı türü: ACL metni
Yorum ipucu: Beklenmeyen kullanıcı/grup izni varsa zinciri zayıflatır
Güvenli sınır: Okuma

5.script -q operations_log.txt

Amaç: Terminal oturumunu kayıt altına almak (işlem izi)
Beklenen çıktı türü: Komutlar ve çıktılarla dolan metin dosyası
Yorum ipucu: “Ben bunu yapmadım” tartışmasını önleyen güçlü izdir; çıkışta exit
Güvenli sınır: Yerel kayıt (sisteme yük bindirmez)

macOS

1.date -u +"%Y-%m-%dT%H:%M:%SZ"

Amaç: UTC zaman damgası üretmek
Beklenen çıktı türü: UTC timestamp metni
Yorum ipucu: Çoklu sistem korelasyonunda UTC, en az sürprizli seçenektir
Güvenli sınır: Okuma

2.systemsetup -getusingnetworktime && systemsetup -getnetworktimeserver

Amaç: Network time kullanımını ve sunucusunu doğrulamak
Beklenen çıktı türü: On/Off + sunucu bilgisi
Yorum ipucu: Beklenen zaman kaynağı mı? Senkron yoksa rapora “korelasyon riski” notu düş
Güvenli sınır: Okuma

3.shasum -a 256 evidence.pcap | tee evidence.pcap.sha256

Amaç: Kanıt hash’i üretmek
Beklenen çıktı türü: Hash satırı + .sha256 dosyası
Yorum ipucu: Hash’i manifest ile birlikte sakla
Güvenli sınır: Okuma/kanıt üretimi

4.ls -le Evidence/

Amaç: Dosya izinlerini ve extended attribute’ları hızlı kontrol etmek
Beklenen çıktı türü: İzin/owner/grup bilgisi
Yorum ipucu: Beklenmeyen “world-readable” izinler risk işaretidir
Güvenli sınır: Okuma

5.log show --last 1h --style syslog > mac_log_extract.txt

Amaç: Zaman pencereli log kesiti almak (minimizasyon)
Beklenen çıktı türü: Log metin dosyası
Yorum ipucu: “Gerektiği kadar” kesit al; ardından hash üretip manifest’e ekle
Güvenli sınır: Okuma/çıktı üretimi

0.7 Wireshark Okuryazarlığı (Modül 0: “kanıt kesiti” disiplini)

Bu modülde Wireshark’ın amacı “avcılık” değil; minimize edilmiş, gerekçeli ve denetlenebilir kanıt kesiti üretmektir.

Wireshark okuryazarlığı: doğru zaman penceresi, doğru filtre ve denetlenebilir kanıt kesiti.

Nasıl yakalarım? (izinli/yerel, düşük risk)

Zaman penceresi: kısa tut (örn. 60–180 sn); “sonsuz yakalama” yerine hedefli pencere.
Arayüz seçimi: sadece gerekli arayüz (yanlış arayüz gereksiz veri toplar).
Ring buffer: uzun yakalama gerekiyorsa küçük dosyalar halinde döndürme yaklaşımı (kanıt yönetimini kolaylaştırır).
Name resolution: kapalı tut (yanlış yönlendiren isim çözümü ve gereksiz veri riskini azaltır).
Daraltma yaklaşımı: capture hedefini “gereken kadar” sınırlamak; gerekçeyi rapora yazmak.

Nasıl okurum? (kanıt seçimi)

Statistics → Conversations / Endpoints: Kim kiminle konuşuyor? Beklenmeyen uç var mı?
Analyze → Expert Information: İletişim hataları/uyarılar var mı?
Zaman çizgisi mantığı: “ilk paket–son paket” aralığı, RoE zaman penceresiyle uyumlu mu?

Nasıl kanıta çeviririm?

“Tam dosya” yerine ilgili paketleri dışa aktar: File → Export Specified Packets (kanıt minimizasyonu).
Kanıt paketi notu ekle: “Bu kesit hangi soruyu cevaplıyor?” + zaman penceresi + hash + saklama yeri.

Dikkat: Trafik yakalama doğası gereği hassastır. Yalnız yetkili ortamda, minimizasyonla ve gerekçeyle yapılır.

0.8 HOW-TO : Mini Şablonlar

A) RoE’nin “olmazsa olmaz” bölümleri (hızlı şablon) (0.5 çıktısına bağlı)

Kapsam / kapsam dışı (IP/DNS/SSID/cloud kimlikleri)
Zaman penceresi + iletişim + deconfliction
Yöntem sınırları + yasaklar (Do Not Harm uyumlu)
Limitler + stop condition + kill-switch
Veri minimizasyonu + kanıt paketi standardı
Rapor formatı: Bulgu → Etki → Öneri → Kanıt

B) Kanıt Paketi Manifest’i (örnek alanlar)

Alan	Açıklama
Dosya adı	Kanıt dosyasının tekil adı
Tür	Log / PCAP / ekran çıktısı
Zaman aralığı	Kesitin başlangıç ve bitiş zamanı
Kaynak	Sistem, cihaz veya arayüz bilgisi
SHA-256	Bütünlük doğrulama değeri
Saklama yeri	Dosyanın güvenli konumu
Erişim yetkisi	Kimlerin erişebileceği
Not	Hangi soruyu cevapladığı / bağlam

0.9 Operasyonel Senaryo (Gating Mantığını Test Eden)

Belirti: vpn.example.com üzerinden erişen kullanıcılar için 14:00–15:00 aralığında kopmalar raporlanıyor. Aynı gün ağ ekibi “politikada değişiklik yaptık” diyor. Senden hızla “bakıp yorum” isteniyor; ancak kapsam, yöntem ve veri toplama sınırları henüz net değil.

Belirti

Hipotez

Analiz

Karar

Rapor

Aşama	Sorulacak soru	Kanıt örneği
Hipotez	Kesintiyi hangi değişkenler açıklıyor olabilir?	Değişiklik kaydı + zaman penceresi
Toplama	Soruya cevap için minimum hangi veriler gerekli?	VPN log kesiti + metrik özeti
Analiz	Zaman korelasyonu ve karşı kanıt tutarlı mı?	NTP doğrulama + zaman çizelgesi
Karar	İnceleme güvenli şekilde devam edebilir mi?	Limit / stop condition / kill-switch durumu
Rapor	Bulgu, etki, öneri ve kanıt net mi?	Hash’li ekler + manifest

Hipotezler

1.Risk/yoğunluk yönetimi zayıf: limit/stop condition yoksa küçük doğrulama bile kesintiyi büyütmüş olabilir.

2.Değişiklik yönetimi sorunu: politika değişikliği sonrası logging/retention veya erişim kapsamı bozulmuş olabilir.

3.Zaman senkronu sorunu: farklı sistem saatleri korelasyonu bozuyor; “sanki aynı anda olmuş” gibi görünen olaylar yanlış bağlanıyor olabilir.

Toplanacak kanıt (minimizasyonla)

Yazılı izin + RoE + kapsam/kapsam dışı (özellikle VPN uçları ve ilgili politika alanı)
Zaman penceresi: 13:30–15:30 (buffer’lı)
Değişiklik kaydı: kim, ne zaman, hangi politika satırı/nesnesi
VPN log kesiti (yalnız ilgili zaman aralığı) + hizmet sağlığı göstergeleri (yanıt süreleri / hata oranı)
Kanıt bütünlüğü: her dosya için hash + manifest + erişim kaydı

Analiz

1.Gating kontrolü: RoE’de limitler/stop condition/kill-switch yazılı mı? Değilse teknik inceleme genişletilmez; önce tamamlanır.

2.Zaman doğrulama: ilgili sistemlerde zaman senkronu doğrulanır; senkron yoksa raporda korelasyon riski belirtilir.

3.Zaman çizelgesi kurma: değişiklik saati ↔ kopma başlangıcı ↔ metrik dalgalanması eşleştirilir.

4.Karşı kanıt arama: “değişiklik yaptıktan sonra mı oldu?” varsayımı yerine, aynı aralıkta başka kaynak (hizmet metrikleri, hata oranı) ile çürütme testi yapılır.

5.Minimizasyon kontrolü: toplanan kanıt, yalnız soruyu cevaplayacak kapsamda mı? Fazla veri varsa kırpılır ve gerekçesi yazılır.

Karar

Kapsam/izin belirsizse: dur, kapsamı yazılılaştır ve deconfliction ile paydaşları hizala.
Kanıt zinciri zayıfsa: önce kanıt paketleme standardını uygula; sonra yorum yap.
Risk limitleri yoksa: limit/stop condition belirlenmeden ek doğrulama genişletilmez.

Rapor (Bulgu → Etki → Öneri → Kanıt)

Bulgu: 14:00–15:00 aralığında kopmalar artmış; aynı gün değişiklik kaydı mevcut; zaman senkronu doğrulaması yapılmadan korelasyon kurulmuş.
Etki: Uzaktan erişimde süreklilik riski; yanlış korelasyonla yanlış düzeltme yapılma riski.
Öneri: RoE’ye limit/stop condition/kill-switch zorunlu eklensin; değişiklik sonrası doğrulama çıktısı standardize edilsin; kanıt paketi manifest+hash zorunlu olsun.
Kanıt: Ek-1 değişiklik kaydı kesiti (hash’li), Ek-2 VPN log kesiti (hash’li), Ek-3 zaman senkron doğrulama çıktıları (hash’li), Ek-4 metrik özet ekranı/notu.

Kendini Değerlendir — Etik ve Yasal

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

1) Denetimde «Yetki» için kanıt isteniyor. Hangi çıktı en uygundur?

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

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

C) Sözlü «biliyoruz» ifadesi

D) Başka modülün raporu

Doğru: A
Gerekçe: «Yetki» denetlenebilir kanıt gerektirir.

2) RoE’de «Do Not Harm» ihlali riski doğdu. İlk adım?

A) Kanıtları silmek

B) Hızı artırmak

C) Stop/kill koşuluna göre durdurmak ve iletişim kanalını kullanmak

D) Tüm ağları kapatmak

Doğru: C
Gerekçe: RoE limitleri üretim güvenliğini korur.

3) Raporlama aşamasında ham kişisel veri eklendi. En uygun düzeltme?

A) Raporu herkese açık paylaşmak

B) Taramayı tekrarlamak

C) Veri minimizasyonu ve maskeleme ile yeniden düzenlemek

D) Logları silmek

Doğru: C
Gerekçe: Raporlama minimizasyon ve gizlilik ilkelerine uymalıdır.

4) Raporlama aşamasında ham kişisel veri eklendi. En uygun düzeltme?

A) Logları silmek

B) Veri minimizasyonu ve maskeleme ile yeniden düzenlemek

C) Taramayı tekrarlamak

D) Raporu herkese açık paylaşmak

Doğru: B
Gerekçe: Raporlama minimizasyon ve gizlilik ilkelerine uymalıdır.

5) Yasal sınır ihlali şüphesi doğdu. Ekip ne yapmalı?

A) Sosyal medyada paylaşım

B) Sessizce devam

C) Hukuk/uyum ile koordine, kapsam dışı aksiyondan kaçınma

D) Varsayılan parolaları deneme

Doğru: C
Gerekçe: Yasal çerçeve dışı faaliyet kabul edilemez.

6) Bir stajyer «Sızma testi sınırı» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

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

B) Araç adı yeterlidir

C) Sadece sınavda sorulursa öğrenilir

D) Yalnızca yöneticiler bilir

Doğru: A
Gerekçe: «Sızma testi sınırı» uygulama ve risk bağlamı olmadan anlamlı değildir.

7) Alt yüklenici test ekibine müşteri verisi aktarılacak. Öncelikli kontrol?

A) Daha hızlı internet

B) SSID gizleme

C) NDA ve veri işleme sözleşmesi / yetki

D) ECB modu

Doğru: C
Gerekçe: Üçüncü tarafla çalışmada sözleşme ve veri koruma şarttır.

8) Raporlama aşamasında ham kişisel veri eklendi. En uygun düzeltme?

A) Veri minimizasyonu ve maskeleme ile yeniden düzenlemek

B) Logları silmek

C) Raporu herkese açık paylaşmak

D) Taramayı tekrarlamak

Doğru: A
Gerekçe: Raporlama minimizasyon ve gizlilik ilkelerine uymalıdır.

9) Yazılı yetki belgesi olmadan üretimde tarama başlatıldı. Bu durumda öncelikli risk nedir?

A) Hukuki ve operasyonel sorumluluk; yetkisiz test

B) Yalnızca performans düşüşü

C) TLS sürüm uyumsuzluğu

D) DNS TTL artışı

Doğru: A
Gerekçe: Yetkili test yazılı onay ve kapsam tanımına dayanır.

10) Yasal sınır ihlali şüphesi doğdu. Ekip ne yapmalı?

A) Sosyal medyada paylaşım

B) Hukuk/uyum ile koordine, kapsam dışı aksiyondan kaçınma

C) Varsayılan parolaları deneme

D) Sessizce devam

Doğru: B
Gerekçe: Yasal çerçeve dışı faaliyet kabul edilemez.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Written authorization Yazılı yetkilendirme; çalışmanın hukuki dayanağı

Rules of Engagement (RoE) Angajman kuralları; kapsam, yöntem sınırları, limitler, dur koşulları, iletişim ve yasakları tanımlar

Scope / Out-of-scope Kapsam / kapsam dışı varlıklar listesi (IP/DNS/SSID/cloud kimliği vb.)

Deconfliction Çakışma yönetimi; ilgili ekiplerle zaman/aksiyon uyumu ve acil temas planı

Do Not Harm Zarar vermeme; kesinti/hasar riskini limitler ve yöntem sınırlarıyla önleme

Rate limit Trafik/işlem yoğunluğunu sınırlama kuralı

Stop condition Önceden tanımlı “dur” koşulları (eşik aşımları, anormallikler)

Kill-switch Acil durdurma mekanizması (kim, nasıl, ne zaman)

Data minimization Amaç için gerekli en az veriyi toplama ilkesi

Retention Log/kanıt saklama süresi disiplini

Hash (SHA-256 vb.) Dosya bütünlüğünü doğrulayan özet değer

Chain of custody Kanıtın toplanmasından saklanmasına kadar erişim ve teslim kayıtları zinciri

Executive summary Yönetici özeti; risk/iş etkisi ve karar noktaları

Technical appendix Teknik ek; kanıt/çıktı/konfig farkı gibi denetlenebilir detaylar

Kapanış: Bu modülde ne kazanıldı?

Yetki

RoE

Limitler

Kanıt

Rapor

Kazanım	Operasyonel değeri
Yetki + kapsam disiplini	Yanlış/izinsiz aksiyon riskini düşürür
RoE ve stop condition	Do Not Harm ilkesini uygulanabilir hale getirir
Minimizasyon + hash + manifest	Kanıtı denetlenebilir ve savunulabilir yapar
Karşı kanıt yaklaşımı	Yanlış korelasyon kaynaklı karar hatalarını azaltır

Yetkisiz/kuralsız teknik çalışmanın, doğru sonuç üretse bile operasyonel ve etik hata olabileceğini.
RoE’nin kapsam, limit, stop condition, kill-switch ve rapor formatını birleştiren çekirdek disiplin olduğunu.
“Do Not Harm” ilkesinin niyet değil; sayısal limit + dur koşulu + acil durdurma ile uygulandığını.
Veri minimizasyonu ve kanıt bütünlüğünün (hash + zincir) raporu “iddia”dan “denetlenebilir çıktı”ya taşıdığını.
“Karşı kanıt” aramanın, yanlış korelasyonu ve aşırı kesin dili azaltıp karar kalitesini yükselttiğini.

MODÜL 1 — Güvenlik Temelleri: Risk, Saldırı Yüzeyi, Mimarî

Kavramsal şema: tehdit ve zafiyet birleşince risk üretilir; saldırı yüzeyi çok giriş noktalı soyut envanterdir; altta derinlemesine savunma katmanları özetlenir.

Bu modül, ağ güvenliğini “hangi cihazı kurarım?” seviyesinden çıkarıp risk temelli savunma mimarisi olarak düşünmeni sağlar. İyi bir ağ güvenliği uzmanı yalnız konfigürasyon yapan kişi değil; ağı varlık (asset) + akış (flow) + risk perspektifinden okuyan, kanıtla konuşan bir mimardır. Burada “saldırı yüzeyi”ni sadece internete açık portlar gibi dar bir liste olarak değil; yanlış yapılandırmalar (misconfiguration), aşırı yetkiler, zayıf egress, görünürlük boşlukları ve yönetim düzlemi (management plane) hataları gibi kategorilerle yönetilebilir bir envantere dönüştürürüz. Tehdit–zafiyet–risk çerçevesiyle önceliklendirme yapar; risk kaydını (risk register) “tek seferlik tablo” değil, yaşayan bir karar mekanizması haline getiririz. Tehdit aktörlerini panik üretmeden, niyet–yetenek–fırsat mantığıyla kavramsallaştırır; MITRE ATT&CK’i ise saldırı öğretmek için değil, ortak dil ve kapsama boşluğu analizi için kullanırız. Modülün sonunda, teoriyi iki somut çıktıya bağlarsın: Saldırı Yüzeyi Envanteri + Risk Register (kanıt zinciriyle).

Bu Dersin Hedefleri

Network güvenliği hedeflerini (CIA + görünürlük + hesap verebilirlik) operasyonel olarak tanımlamak.
Tehdit–zafiyet–risk ilişkisini kurup olasılık × etki ile önceliklendirme yapmak.
Kritik varlıkları (“crown jewels”) belirleyip saldırı yüzeyini kategorilerle envantere dökmek.
Tehdit aktörlerini kavramsal düzeyde sınıflandırarak savunma kararlarına tarafsız girdi üretmek.
Savunma mimarisi ilkelerini (defense-in-depth, least privilege, default-deny, management plane ayrımı) ağ bağlamında uygulamak.
MITRE ATT&CK yaklaşımını ortak dil olarak kullanıp “hangi davranışa karşı hangi kanıt var?” sorusunu sistematikleştirmek.
HOW-TO çıktısı üretmek: Risk Register + Saldırı Yüzeyi Envanteri + misconfiguration kontrol listesi + doğrulama/rollback adımları.

1.1 Network güvenliği hedefleri

Ağ güvenliğinin hedefi “trafik engellemek” değildir; işin güvenli ve sürdürülebilir işlemesini sağlayan ölçülebilir hedefler bütünüdür. Temel çerçeve CIA triadıdır:

Gizlilik

Bütünlük

Erişilebilirlik

Görünürlük

Hesap verebilirlik

Hedef	Operasyonel karşılığı	Kanıt/ölçüm örneği
Gizlilik	Yetkisiz erişimi engelleme	TLS kullanımı, erişim logları
Bütünlük	Veri değişimini fark edilebilir kılma	Hash/doğrulama çıktıları, konfig değişiklik kayıtları
Erişilebilirlik	Servis sürekliliğini koruma	Uptime, hata oranı, kapasite metrikleri
Görünürlük	Akışları ve olayları izleyebilme	Flow/log/PCAP kapsamı ve tutarlılığı
Denetlenebilirlik	Karar ve değişiklikleri geriye izleyebilme	Kim-ne-zaman değişiklik kaydı + rapor izi

Orta/ileri ağ güvenliğinde bunlara ek olarak görünürlük (visibility), hesap verebilirlik (accountability), dayanıklılık (resilience) ve denetlenebilirlik (auditability) kritik hale gelir. Çünkü “güvenlik” iddiası kanıtla desteklenmiyorsa, pratikte güvenlik yoktur.

Etki / risk

Hedefler net değilse savunma “rastgele kontrol ekleme”ye döner: maliyet artar, risk aynı kalabilir.
Erişilebilirlik göz ardı edilirse “güvenlik” hamleleri kesinti üretir; Do Not Harm bozulur.
Görünürlük zayıfsa en iyi politika bile “çalışıyor mu?” sorusuna cevap veremez; olay anında karar verilemez.

Tespit sinyali / kanıt

“Bu kural hangi hedefi destekliyor?” sorusuna cevap yoksa politika amaç–sonuç kopuktur.
Kritik akışlar için log/flow/pcap yoksa görünürlük açığı vardır.
Değişiklik kaydı yoksa (kim, neyi, neden değiştirdi?) denetlenebilirlik riski doğar.

Savunma kontrolü / düzeltme yaklaşımı

Her kontrolü bir hedefe bağla: “Bu kural/segment şu riski şu hedef için azaltır.”
Hedefleri ölçülebilir yap: örn. “kritik akışlarda şu log zorunlu”, “yönetim arayüzlerine yalnız yönetim segmentinden erişim.”
Raporlama omurgasını baştan düşün: Bulgu → Etki → Öneri → Kanıt (rapor formatı), hedeflerin kanıtla gösterilmesini zorlar.

Dikkat: “Güvenlik hedefi” kontrol listesi değildir.

İpucu: Her hedef için “bozulursa işte ne durur?” cümlesini ekle.

1.2 Tehdit–zafiyet–risk çerçevesi

Tehdit: zarar verme potansiyeli (niyet + yetenek + fırsat).
Zafiyet: kontrol boşluğu/hatalı tasarım/hatalı yapılandırma (misconfiguration, aşırı izin, eksik log, açık yönetim portu vb.).
Risk: tehdidin zafiyetten yararlanması halinde oluşan olasılık × etki.

Pratikte etki, büyük ölçüde varlık değeri ile ilgilidir; bu yüzden bazı ekipler riski “tehdit + zafiyet + varlık değeri” bileşenleriyle konuşur. Aynı şeyi daha operasyonel söylemek gerekirse:

Olasılık Tehdit + zafiyet koşullarının gerçekleşme ihtimali

Etki Varlığın değeri ve iş etkisi

Etki / risk

Tehdit ile zafiyeti karıştırmak yanlış öncelik üretir: “popüler tehdit” gündemi gerçek açıklara baskın gelir.
Etkiyi ölçmeden sadece olasılığa odaklanmak, kritik iş süreçlerini kırılgan bırakır.
Risk kaydı yoksa aynı tartışmalar döner; kurum “öğrenmez”.

Tespit sinyali / kanıt

Risk konuşmaları kanıtsız kanaate dayanıyorsa (log/flow/pcap/konfig yoksa) doğruluk riski yüksektir.
Aynı olayın tekrar etmesi, kalıcı kontrol eksikliğine işaret eder.
“Kimin onayıyla kabul edildi?” sorusu yanıtsızsa risk yönetişimi zayıftır.

Savunma kontrolü / düzeltme yaklaşımı

Basit ama tutarlı bir skala seç (örn. 1–5 olasılık, 1–5 etki) ve standardize et.
Risk kaydına şu alanları zorunlu koy: varlık/akış, zafiyet kategorisi, mevcut kontrol, kanıt referansı, sahip, hedef tarih, kapanış kriteri, artık risk.
Risk azaltımını kanıtla bağla: “Değişiklik sonrası hangi kanıtla doğrulayacağız?”

BYPASS / erişim farkındalığı (savunma formatı):

Kategori

Amaç

İz/sinyal

Kontrol

Kanıt

Alan	İçerik
Kategori	Zayıf egress / aşırı izin
Amaç	Dışarı beklenmedik bağlantı kurmak (kavramsal)
İz/sinyal	Flow’da uzun oturumlar, proxy log’da ilk kez görülen domain
Kontrol	Egress allowlist, DNS/proxy loglama, politika gözden geçirme
Kanıt örneği (uydurma)	“203.0.113.25:443’e 30 dakikalık oturum; aynı dakikada cdn.example.net ilk kez görülmüş.”

1.3 Tehdit aktörleri (kavramsal)

Tehdit aktörü sınıfları “kim yaptı?”yı kanıtlamaz; hangi davranışı beklemeliyiz? sorusuna yardımcı olur. Ağ savunmasında tipik aktör kalıpları:

Fırsatçı

Hedefli

İç risk

Tedarik

APT

Aktör kalıbı	Davranış özeti
Fırsatçı / otomasyon odaklı	Zayıf halkayı arar, hızlı dener.
Hedefli	Belirli varlık veya iş sürecine odaklanır.
İç risk (kötü niyet + ihmal)	Yanlış yapılandırma veya uygunsuz değişiklik, dış saldırıyla benzer etki doğurabilir.
Üçüncü taraf / tedarik	VPN, SaaS entegrasyonları, yönetilen servisler üzerinden risk taşır.
Yüksek kapasiteli (state-sponsored / APT kalıbı)	Uzun süreli, gizli kalmaya dönük davranışlar gösterebilir.

Etki / risk

Aktörü yanlış varsaymak gereksiz pahalı kontrol ya da kritik boşluk üretir.
İç risk yalnız “kötü niyet” değildir; değişiklik disiplini zayıfsa “kazaen açıklık” sık görülür.
Üçüncü tarafı yok saymak görünmez yüzey bırakır.

Tespit sinyali / kanıt

Fırsatçı kalıp: çok sayıda kısa deneme, çok hedefli benzer örüntüler (kurum içi telemetri).
İç risk: değişiklikten sonra anomali, yönetim erişiminde beklenmedik artış.
Üçüncü taraf: yeni bağlantı yönleri, yeni sertifika/endpoint kalıpları; “ilk kez görülme” sinyalleri.

Savunma kontrolü / düzeltme yaklaşımı

Aktör varsayımını risk kaydına tek cümle yaz: “En muhtemel kalıp X; çünkü Y kanıtı var.”
Kontrol yatırımını davranışa bağla: fırsatçıya hijyen + görünürlük; hedefliye segmentasyon + egress + güçlü izleme; iç riske değişiklik disiplini + yönetim düzlemi koruması.
Belirsizliği dürüstçe yönet: “aktör kalıbıyla uyumlu sinyal” dili kullan.

Dikkat: Aktör etiketi kanıt değildir; önce “ne gördük?” gelir.

İpucu: “Bu davranışı yakalamak için hangi veri kaynağım eksik?” diye sor.

1.4 Savunma mimarisi ilkeleri

Savunma mimarisi, tek cihaza güvenmek yerine katmanlı ve tutarlı tasarım kurmaktır:

Katmanlı

Min. yetki

Segment

Yönetim

Görünürlük

Değişim

İlke	Ne sağlar?
Defense-in-depth	Bir katman aşılırsa diğer katman durdurur veya iz bırakır.
Least privilege + default-deny	Gereken akışlar tanımlıdır; gerekmeyenler yoktur.
Segmentasyon	Fonksiyonel bölgeler (user/server/IoT/DMZ) ile yanal yayılım sınırlanır.
Management plane ayrımı	Yönetim arayüzleri ayrı segment, ayrı erişim politikası ve ayrı izleme ile korunur.
Görünürlük-by-design	Log/flow/pcap mimariye gömülüdür; sonradan yamalanmaz.
Değişiklik disiplini	Drift’i önlemek için etiketleme, gerekçe, doğrulama ve geri dönüş planı uygulanır.

Etki / risk

Tek noktaya güvenmek, yanlış yapılandırmada büyük etki üretir.
Yönetim düzlemi karışırsa “kontrolün kendisi” kontrolsüz kalır.
Görünürlük sonradan eklenirse kör noktalar kalır; olay anında kanıt üretilemez.

Tespit sinyali / kanıt

“Kim, nereden yönetiyor?” sorusu yanıtsızsa yönetim düzlemi riski vardır.
Benzer ortamlarda farklı politika davranışı drift sinyalidir.
Kritik akışta kanıt üretilememesi (log yok) görünürlük boşluğudur.

Savunma kontrolü / düzeltme yaklaşımı

Mimariyi “akış matrisi”yle düşün: kaynak bölge → hedef bölge → servis → gerekçe → kanıt kaynağı.
Default-deny’i kademeli uygula: önce kritik allowlist + doğrulama, sonra genişleme.
Değişiklikte önce düşük riskli doğrulama: kanıt olmadan genişletme yok.

BYPASS / erişim farkındalığı (savunma formatı):

Kategori

Amaç

İz/sinyal

Kontrol

Kanıt

Alan	İçerik
Kategori	Segmentasyon boşluğu
Amaç	Beklenmeyen doğu-batı erişimi (kavramsal)
İz/sinyal	Flow’da yeni iç segment konuşmaları
Kontrol	Akış matrisi, FW/ACL doğrulaması, mikro-segment
Kanıt örneği (uydurma)	“198.51.100.20 → 198.51.100.80 445/TCP ilk kez; aynı gün değişiklik kaydı var.”

1.5 Referans/ortak dil (MITRE ATT&CK yaklaşımı)

MITRE ATT&CK, savunma ekipleri için ortak dil sağlar:

İletişim

Kapsama

Raporlama

Kullanım	Odak sorusu / çıktı
İletişim	“Bu sinyal hangi davranış sınıfıyla uyumlu?”
Kapsama analizi	“Bu davranışı görebilmek için hangi veri kaynağı lazım?”
Raporlama	Bulguyu standart ve izlenebilir şekilde ifade etmek.

Burada ATT&CK bir “checklist” değildir; kanıt–sinyal–kontrol eşlemesi için referanstır.

Etki / risk

Ortak dil yoksa SOC, network ve yönetim aynı olayı farklı isimlerle konuşur; boşluklar gizlenir.
ATT&CK’i kanıtsız etiketlemek yanlış alarm ve yanlış yönlendirme üretir.
Veri kaynağı eşlemesi yapılmazsa görünürlük açıkları fark edilmez.

Tespit sinyali / kanıt

ATT&CK eşlemesinde “hangi log/flow/pcap alanı?” sorusu yanıtlanmalı.
“Bu davranışı göremiyoruz” tespiti de kanıttır: kapsama boşluğunu gösterir.

Savunma kontrolü / düzeltme yaklaşımı

Eşlemeyi kanıtla bağla: ATT&CK referansı → veri kaynağı → alanlar → örnek sinyal → kontrol önerisi.
Kapsama matrisi üret: davranış sınıfı → veri kaynağı → kontrol → doğrulama adımı.
Kesinlik yerine doğruluk: “uyumlu sinyaller” dili, kanıtı aşmayan raporlama üretir.

İpucu: Her olayda şu soruyu sor: “Bu davranışı tekrar görürsem, en az riskle hangi kanıtı toplarım?”

1.6 HOW-TO: Risk Register + Saldırı Yüzeyi Envanteri

Bu HOW-TO, teoriyi iki yaşayan çıktıya indirger:

Yüzey envanteri

Risk kaydı

Çıktı	Kapsam
Saldırı Yüzeyi Envanteri	Varlıklar + giriş noktaları + yönetim düzlemi + bağımlılıklar + izinli akışlar + görünürlük kaynakları.
Risk Register	Her bulgu için risk ifadesi, skor, sahiplik, hedef tarih, kapanış kriteri ve kanıt referansı.

Etki / risk

Envanter yoksa “bilmediğini korumaya çalışma” başlar.
Risk kaydı yoksa bulgular “tek seferlik panik” olur.
Kanıt bağlanmazsa kayıt denetlenemez; güvenilirlik düşer.

Tespit sinyali / kanıt

Yönetim arayüzleri nerede? Hangi akışlar izinli? Hangi log kaynakları var? “Bilmiyoruz” alanları sinyaldir.
Değişiklik sonrası envanter güncellenmiyorsa drift riski büyür.
Kanıtsız risk maddeleri karar kalitesini düşürür.

Savunma kontrolü / düzeltme yaklaşımı

Envanteri akış merkezli tut: varlık → bölge → izinli akış → kontrol noktası → kanıt kaynağı.
Risk kayıtlarını kapanış kriteri + kanıtla bağla.
Sürdürülebilirlik: sahip ataması + periyodik gözden geçirme + değişiklik tetikleyicileri.

1.7 Komut & Araç Okuryazarlığı (White-Hat: denetim / doğrulama / kanıt)

Aşağıdaki komutlar yalnızca izinli/kurum içi yetkili ortam veya tamamen yerel lab için; envanter çıkarımı, bağlantı/politika doğrulama ve kanıt paketleme amaçlıdır. Geniş kapsamlı hedef keşfi, tarama, istismar veya bypass “how-to” yoktur.

Zaman

Komut

Çıktı

Hash

Kanıt bağı

Platform	Odak	Çıktı örneği
Windows	IP/port/firewall/route/ARP doğrulama	Konfigürasyon ve port kanıt dosyaları + SHA-256
Linux	Arayüz, rota, DNS, komşu tablosu	Text çıktılar + manifest.sha256
macOS	Arayüz, dinleyen servis, default route	Kanıt klasörü + hash manifest

Kanıt disiplininin mini standardı (her komutta)

Zaman damgası al: (UTC tercih)
Çıktıyı dosyaya yaz: isimlendirme standardıyla
Hash üret: SHA-256
Not düş: “Bu çıktı hangi soruya cevap veriyor?”

Windows (PowerShell / CLI)

1.Get-Date -Format o

Amaç: Kanıt paketine standart zaman damgası eklemek
Beklenen çıktı türü: ISO 8601 zaman damgası
Yorum ipucu: Tüm çıktılar aynı saat referansıyla ilişkilensin
Güvenli sınır: Okuma

2.Get-NetIPConfiguration | Out-File .\evidence\net_ipconfig.txt

Amaç: IP/DNS/Gateway yapılandırmasını envantere almak
Beklenen çıktı türü: Arayüz bazlı konfigürasyon metni
Yorum ipucu: DNS sunucuları, default gateway, interface alias kritik
Güvenli sınır: Okuma (yerel)

3.Get-NetTCPConnection -State Listen | Select LocalAddress,LocalPort,OwningProcess | Out-File .\evidence\listening_ports.txt

Amaç: Yerel dinleyen portları (yerel saldırı yüzeyi) kanıtlamak
Beklenen çıktı türü: Port–process tablosu
Yorum ipucu: 0.0.0.0/:: gibi tüm arayüz dinlemeleri daha kritiktir
Güvenli sınır: Okuma (tarama değil)

4.netsh advfirewall show allprofiles > .\evidence\fw_profiles.txt

Amaç: Yerel firewall profil durumunu kanıtlamak
Beklenen çıktı türü: Profil ayar özeti
Yorum ipucu: Profil kapalıysa risk kaydına “kontrol eksikliği” olarak gir
Güvenli sınır: Okuma

5.route print > .\evidence\routes.txt

Amaç: Rota tablosunu kanıtlamak
Beklenen çıktı türü: Rota metni
Yorum ipucu: Default route ve metric değerleri akış varsayımlarını etkiler
Güvenli sınır: Okuma

6.arp -a > .\evidence\arp_neighbors.txt

Amaç: Yerel komşu (IP–MAC) eşleşmelerini kanıtlamak (pasif gözlem)
Beklenen çıktı türü: ARP tablosu
Yorum ipucu: “ilk kez görülen” komşular envanter doğrulaması için sinyal olabilir
Güvenli sınır: Okuma

7.Get-FileHash .\evidence\listening_ports.txt -Algorithm SHA256

Amaç: Kanıt bütünlüğünü sabitlemek
Beklenen çıktı türü: SHA-256 hash
Yorum ipucu: Hash’i “manifest” dosyasına ekle
Güvenli sınır: Okuma/kanıt üretimi

Linux

1.date -u +"%Y-%m-%dT%H:%M:%SZ"

Amaç: UTC zaman damgası üretmek
Beklenen çıktı türü: ISO benzeri zaman damgası
Yorum ipucu: PCAP/log kesitleriyle zaman hizalaması
Güvenli sınır: Okuma

2.ip -brief addr | tee evidence/ip_addr.txt

Amaç: Arayüz ve IP envanteri
Beklenen çıktı türü: Kısa arayüz listesi
Yorum ipucu: Beklenmeyen tünel/vlan arayüzleri “gizli yüzey” olabilir
Güvenli sınır: Okuma

3.ss -lntup | tee evidence/listening_ports.txt

Amaç: Dinleyen TCP/UDP portları ve süreçleri kanıtlamak
Beklenen çıktı türü: Port–process tablosu
Yorum ipucu: 0.0.0.0:PORT vs 127.0.0.1:PORT farkı kritiktir
Güvenli sınır: Okuma

4.ip route show | tee evidence/routes.txt

Amaç: Rota tablosu kanıtı
Beklenen çıktı türü: Rota listesi
Yorum ipucu: Default route beklenmeyen gateway’e gidiyorsa risk sinyalidir
Güvenli sınır: Okuma

5.resolvectl status | tee evidence/dns_status.txt (sisteme göre muadil olabilir)

Amaç: DNS çözümleme yapılandırmasını kanıtlamak
Beklenen çıktı türü: DNS sunucuları ve arayüz eşlemesi
Yorum ipucu: Resolver önceliği beklenmeyen çözümlemelere yol açabilir
Güvenli sınır: Okuma

6.ip neigh | tee evidence/neigh_table.txt

Amaç: Komşu tablosu (IP–MAC) pasif kanıtı
Beklenen çıktı türü: Neighbor listesi
Yorum ipucu: Yeni/tekil MAC’ler envanter doğrulama tetikleyicisi olabilir
Güvenli sınır: Okuma

7.sha256sum evidence/*.txt | tee evidence/manifest.sha256

Amaç: Kanıt dosyaları için toplu hash manifest’i üretmek
Beklenen çıktı türü: Hash listesi
Yorum ipucu: Risk register “kanıt ref” alanına manifest’i bağla
Güvenli sınır: Okuma/kanıt üretimi

macOS

1.date -u +"%Y-%m-%dT%H:%M:%SZ"

Amaç: UTC zaman damgası
Beklenen çıktı türü: Zaman damgası
Yorum ipucu: Kanıt zinciri için tek referans
Güvenli sınır: Okuma

2.networksetup -listallhardwareports > evidence/hardware_ports.txt

Amaç: Arayüz–MAC eşleşmesini envantere almak
Beklenen çıktı türü: Port listesi
Yorum ipucu: Sanal arayüzler (VPN/tünel) akış envanterinde kritik olabilir
Güvenli sınır: Okuma

3.ifconfig > evidence/ifconfig.txt

Amaç: Arayüz/IP detaylarını kanıtlamak
Beklenen çıktı türü: Arayüz detay metni
Yorum ipucu: inet, ether, MTU alanları kıymetli
Güvenli sınır: Okuma

4.lsof -i -P -n | grep LISTEN > evidence/listening_ports.txt

Amaç: Hangi uygulamanın hangi portu dinlediğini görmek
Beklenen çıktı türü: Uygulama–port listesi
Yorum ipucu: Beklenmeyen servis “misconfiguration” adayıdır
Güvenli sınır: Okuma

5.route -n get default > evidence/default_route.txt

Amaç: Varsayılan gateway kanıtı
Beklenen çıktı türü: Gateway/arayüz bilgisi
Yorum ipucu: Yanlış gateway, segmentasyon varsayımlarını bozar
Güvenli sınır: Okuma

6.scutil --dns | head -n 80 > evidence/dns_status.txt

Amaç: DNS resolver kesiti almak
Beklenen çıktı türü: DNS resolver bilgisi
Yorum ipucu: Resolver sırası ve arayüz eşlemesi kritik
Güvenli sınır: Okuma

7.shasum -a 256 evidence/* | tee evidence/manifest.sha256

Amaç: Kanıt bütünlüğünü sabitlemek
Beklenen çıktı türü: Hash manifest
Yorum ipucu: Rapor eklerinde hash manifest mutlaka yer alsın
Güvenli sınır: Okuma/kanıt üretimi

Wireshark / tshark / tcpdump — “yakala, oku, kanıta çevir” (modül 1 seviyesinde derin okuryazarlık)

1) Nasıl yakalarım? (capture stratejisi)

Amaç: “Her şeyi yakala” değil; soruyu yanıtlayacak kadar kanıt üret.
Zaman penceresi: kısa (örn. 60–180 sn) ve gerekçeli.
Dosya yönetimi: ring buffer kullan (dosya boyutu/süreye göre döndür) → büyük yakalama yerine küçük parçalar.
Hassas veri minimizasyonu: yalnız gerekli protokoller/hostlar; mümkünse metadata odaklı filtreleme.
Not: Üretim ortamında capture, mutlaka yetki ve veri koruma kurallarıyla yapılır.

2) Nasıl okurum? (ekranlar, filtreler, alanlar)

Display filter mantığı: önce daralt, sonra detay. Örnekler (uydurma IP’lerle):

o ip.addr == 198.51.100.20 (tek uç odaklı)

o dns (DNS trafiği)

o tls (TLS oturumları)

o tcp.port == 443 (servis odaklı)

o tcp.flags.syn == 1 && tcp.flags.ack == 0 (bağlantı başlatma denemeleri; “normal” ile kıyas için)

3) Okuma ekranları (kanıta dönük):

o Statistics → Endpoints: “kimler var?” envanter hissi

o Statistics → Conversations: “kim kiminle konuşuyor?” akış kanıtı

o Expert Info: anomali/uyarıların özet görünümü

o Follow Stream: belirli akışın bağlamı (dikkat: hassas veri minimizasyonu)

4) Nasıl kanıta çeviririm? (çıktı üretimi)

İlgili Endpoints/Conversations tablolarını kopyala/export et (CSV olabilir), ekran görüntüsü al, pcap’ı sakla.
Kanıt paketine ekle:

o Zaman penceresi, arayüz, filtreler (ne yakaladın/ne yakalamadın)

o Hash manifest (pcap dahil)

o “Bu kanıt hangi hipotezi doğrular/çürütür?” notu

Dikkat: Wireshark çıktısı tek başına “sonuç” değildir; gözlem–yorum ayrımını koru.

İpucu: Kanıt toplarken önce şu cümleyi yaz: “Kanıt, X hipotezini doğrulamak/çürütmek için toplanıyor.”

1.8 HOW-TO — Risk Register + Saldırı Yüzeyi Envanteri (Runbook)

Aşağıdaki runbook, tek seferlik belge yazımı değil; değişikliklerle güncellenen yaşayan bir mekanizmadır.

Hazırlık

Envanter

Doğrulama

Kanıt

Rollback

Faz	Ana soru	Beklenen çıktı
Hazırlık	Neyi, kimle, hangi sınırda yönetiyoruz?	Kapsam + sahiplik + şablonlar
Uygulama	Envanterde ne var, ne eksik?	Yüzey envanteri + kontrol listesi
Doğrulama	Bulguyu ne doğrular / ne çürütür?	Karşı kanıtla netleşen risk
Kanıt paketleme	Bu bulgu nasıl denetlenir?	Manifest + hash + referanslı kayıt
Rollback	Hatalı/fazla veri nasıl geri alınır?	Sürüm ve düzeltme izi

Hazırlık

Kapsam: Hangi bölgeler/servisler? (edge, DMZ, user, server, yönetim, uzaktan erişim)
Sahiplik: Her bölgenin teknik sahibi ve iş sahibi.
Varlık tier’ları (örnek sınıflama):

Tier-0 (Kritik / Crown Jewels): kimlik altyapısı, veritabanları, yedekleme sistemleri

Tier-1 (Yönetim): firewall/switch yönetim arayüzleri

Tier-2 (Kullanıcı): istemciler, kurumsal Wi-Fi

Tier-3 (Dış/DMZ): internetten erişilen servis uçları

Kanıt kaynakları listesi: konfig çıktıları, değişiklik kayıtları, flow/log özetleri, (gerekirse) kısa pcap kesitleri
Şablonlar: Envanter tablosu + Risk register tablosu + Kanıt manifest’i

Uygulama (envanter çıkarma)

Saldırı Yüzeyi Envanteri — önerilen alanlar

Varlık ID / Ad (uydurma: fw-edge-01, vpn-gw-01)
Bölge (edge/DMZ/iç/yönetim)
Giriş noktaları (servis uçları + yönetim arayüzleri)
İzinli akışlar (kaynak → hedef → servis/port → gerekçe)
Bağımlılıklar (üçüncü taraf/SaaS/remote access)
Görünürlük (log/flow/pcap nerede?)
Kritik varsayımlar (örn. “yönetim yalnız yönetim segmentinden”)
Kanıt referansı (dosya/ekran görüntüsü + hash)

Misconfiguration mini kontrol listesi (E/H)

Yönetim arayüzleri yetkisiz bölgeden erişilebilir mi?
Aşırı izinli politikalar var mı (gereksiz geniş akışlar)?
Kritik akışlarda log/flow yok mu?
Varsayılan/uygunsuz ayarlar (ör. gereksiz servis) var mı?
Değişikliklerin gerekçesi/etiketi yok mu?

Doğrulama (karşı kanıt mantığı)

Her bulgu için iki soru zorunlu:

“Bu belirtiyi ne doğrular?” (hangi kanıt alanı/çıktı?)
“Ne çürütür?” (alternatif açıklama ve karşı kanıt)

Örn. “Beklenmeyen egress” → doğrulayan: flow + proxy/DNS log eşleşmesi; çürüten: değişiklik kaydı + iş gerekçesi + allowlist onayı.

Kanıt paketleme

Çıktıları standart isimlendir: YYYYMMDD_mod1_asset_inventory_v1.csv gibi
Manifest oluştur: dosya adı + zaman + hash + kısa not
Riske kanıt bağla: Risk register satırı, manifest satırına referans verir

Geri dönüş / rollback

Bu modülde rollback, genellikle belge/kanıt disiplini rollback’idir:

o Kanıtsız/yanlış satır → “geri çekildi” etiketi + yeniden doğrulama

o Fazla veri toplandıysa → minimizasyon + kaldırma kaydı

o Şablon/versiyon hatası → sürüm güncelle + değişiklik notu

1.9 Operasyonel Senaryo — “Hayalet Varlık” (envanter–risk–kanıt zinciri)

Belirti: İç ağ akış özetinde, envanterde görünmeyen bir IP’nin kısa aralıklarla farklı istemcilerden bağlantı aldığı görülüyor. Örnek gözlem (uydurma): 198.51.100.45 adresi, gün içinde pek çok istemciyle 80/TCP konuşmuş.

Belirti

Hipotez

Analiz

Karar

Rapor

Aşama	Odak	Kanıt örneği
Hipotez	Hayalet varlık meşru mu / yanlış konumda mı?	Envanter + değişiklik geçmişi
Toplama	Minimum doğrulama verisi nedir?	Flow + DHCP + ARP/neighbor
Analiz	Zafiyet türü ve etki seviyesi nedir?	Bölge, tier, erişim örüntüsü
Karar	İzole et, taşı, dokümante et?	En az riskli düzeltme planı
Rapor	Bulgu/Etki/Öneri/Kanıt net mi?	Hash’li ekler + manifest

Hipotezler

1.Meşru ama envantere işlenmemiş bir test/ara servis (policy ihlali / dokümantasyon açığı).

2.Yanlış VLAN/segment yerleşimi nedeniyle “olması gereken yerde olmayan” bir cihaz (segmentasyon boşluğu).

3.Yanlış yapılandırılmış bir cihaz, beklenmeyen şekilde servis yayınlıyor (misconfiguration).

Not: Bu hipotezler “kim yaptı?” değil; “ne olabilir?” sorusuna kanıt odaklı yaklaşım üretir.

Toplanacak kanıt (minimum, izinli)

Flow özeti (zaman penceresi + kaynak/hedef + port)
DHCP/varlık kayıtları (bu IP’ye kira verilmiş mi?)
Yerel komşu tabloları (ARP/neighbor): IP–MAC eşleşmesi (pasif)
Gerekirse tekil ve düşük etkili doğrulama: servis başlığı (ör. yalnız HEAD isteği)
Kanıt bütünlüğü: çıktı dosyaları + SHA-256 manifest

Analiz adımları (gözlem–yorum ayrımıyla)

1.Gözlemi netleştir: Flow’da “ilk kez görülme” mi, yoksa uzun süredir var mı?

2.Karşı kanıt ara: Aynı saatlerde planlı değişiklik var mı? DHCP kaydı var mı?

3.Envanterle kıyasla: Tier-0/1/2/3 hangi bölgede olmalı? Bu varlık nereye ait görünüyor?

4.Risk çerçevesine oturt:
a.Zafiyet kategorisi: dokümantasyon açığı mı, segmentasyon boşluğu mu, misconfiguration mı?
b.Olasılık: kaç kez/kaç istemciyle?
c.Etki: hangi bölgeyi etkiliyor, “crown jewels” yakınında mı?

5.Karar üret (en az riskli seçenek): Önce görünürlüğü artır, sonra düzeltme planı (kapat/taşı/izole) öner.

Karar

Kanıt, bunun meşru bir test servisi olduğunu gösteriyorsa: envantere işlenir, uygun bölgeye taşınır, politika netleştirilir.
Segmentasyon boşluğu görünüyorsa: akış matrisi güncellenir, doğru bölgeleme önerilir.
Misconfiguration sinyali kuvvetliyse: servis yayınlama koşulları (host firewall, servis konfig) gözden geçirilir.

Rapor (Bulgu → Etki → Öneri → Kanıt)

Bulgu: 198.51.100.45 adresli varlık, envanterde kayıtlı olmamasına rağmen iç ağda 80/TCP trafiğiyle görünmektedir.
Etki: Envanter ve segmentasyon varsayımları bozulduğu için yanlış pozitif/negatif ve olası yetkisiz servis yayını riski artar.
Öneri: Varlığın sahibi ve amacı tespit edilerek envantere işlenmesi; doğru bölgeye taşınması veya izolasyonu; ilgili akışların allowlist’e bağlanması ve görünürlüğün (flow/log) standardize edilmesi.
Kanıt: Flow özeti (hash’li), komşu tablosu kesiti (hash’li), DHCP/kayıt kontrol kesiti (hash’li), kanıt manifest’i (SHA-256).

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

CIA Triadı Gizlilik–Bütünlük–Erişilebilirlik: bilgi güvenliğinin temel hedefleri

Asset / Varlık Korunması gereken sistem, cihaz, servis veya veri

Crown Jewels İş durmasına veya büyük zarara neden olacak kritik varlıklar (Tier-0)

Risk Olasılık × etki; kabul edilebilir seviyeye indirilmeye çalışılır

Tehdit Zarar verme potansiyeli (niyet + yetenek + fırsat)

Zafiyet Kontrol boşluğu / hatalı tasarım / yanlış yapılandırma

Misconfiguration Yanlış yapılandırma: aşırı izin, açık yönetim arayüzü, eksik log vb.

Attack Surface / Saldırı Yüzeyi Erişilebilir giriş noktaları + yapılandırma/izin/görünürlük boşluklarının toplamı

Defense-in-Depth Katmanlı savunma; tek kontrol yerine çok katman

Least Privilege En az ayrıcalık; yalnız gerekli erişim/akış

Default-Deny Varsayılan engelleme; izinler açıkça tanımlı

Management Plane Yönetim düzlemi; cihaz/servis yönetim arayüzleri ve kontrol kanalı

Policy Drift Politikanın zamanla standarttan sapması (değişiklik disiplini zayıflığı)

MITRE ATT&CK Saldırgan davranışlarını sınıflandıran çerçeve; savunmada ortak dil/kapsama analizi için kullanılır

Risk Register Risklerin sahiplik, hedef tarih, kapanış kriteri ve kanıtla yönetildiği yaşayan kayıt

Kendini Değerlendir

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

Bir ekip “gizlilik–bütünlük–erişilebilirlik” hedeflerini net yazmadan yeni firewall kuralları ekliyor. Aşağıdakilerden hangisi en olası sonuçtur?

A) Kontrol sayısı artar, risk otomatik azalır

B) Maliyet artar, risk azalması belirsiz kalır

C) Görünürlük kendiliğinden artar

D) Denetlenebilirlik otomatik sağlanır

E) Erişilebilirlik mutlaka iyileşir

Doğru: B
Gerekçe: Hedef–kontrol eşleşmesi yoksa “rastgele kontrol ekleme” olur. A/C/D/E otomatik değildir; hatta tersine bozulabilir.

Risk kaydında “olası veri sızıntısı” yazıyor fakat hiçbir log/flow/pcap referansı yok. Bu durum en doğru nasıl yorumlanır?

A) Risk kaydı yeterlidir; kanıt opsiyoneldir

B) Kanıt yoksa risk otomatik düşüktür

C) Denetlenebilirlik zayıftır; karar kalitesi düşer

D) ATT&CK etiketi eklenirse kanıt yerine geçer

E) Sadece firewall kuralı eklemek sorunu çözer

Doğru: C
Gerekçe: Kanıtsız risk, izlenebilir değildir. A/D yanlış; B temelsiz; E kanıt ve kök neden görmeden “tek kontrol” yaklaşımıdır.

“Tehdit aktörü state-sponsored olabilir” cümlesi olay raporunda kanıt olmadan yer alıyor. En doğru yaklaşım hangisidir?

A) Aktör etiketi kesin yazılmalı; profesyonellik göstergesidir

B) Aktör etiketi yerine gözlemsel sinyaller ve kanıt yazılmalı

C) Aktörü yazmak zorunludur; kanıt olmasa da olur

D) Aktör kesinleşmeden containment yapılmaz

E) Aktör yazılırsa artık risk kaydı gerekmez

Doğru: B
Gerekçe: Aktör etiketi kanıt değildir; “uyumlu sinyaller + kanıt” esastır. D de hatalı: aktör kesinliği beklemeden risk-temelli aksiyon alınabilir.

“Risk = olasılık × etki” yaklaşımında “etki”yi en iyi temsil eden unsur hangisidir?

A) Sadece port numarası

B) Varlığın iş değeri ve olası iş kesintisi

C) Sadece IDS alarm sayısı

D) Sadece kullanıcı sayısı

E) Sadece şifreleme kullanımı

Doğru: B
Gerekçe: Etki, iş etkisi/varlık değeriyle ilişkilidir. Diğerleri tek başına etkiyi temsil etmez.

Bir ağda management plane ile kullanıcı trafiği aynı segmentte. Bu durumun en kritik mimari riski hangisidir?

A) DNS çözümlemesi hızlanır

B) Loglar otomatik iyileşir

C) Yönetim arayüzleri daha geniş erişime açılabilir

D) MTU değeri düşer

E) VPN otomatik devreye girer

Doğru: C
Gerekçe: Yönetim düzlemi ayrımı yoksa yönetim yüzeyi genişler. A/B/D/E konuyla doğrudan ilgili değil.

Wireshark’ta kanıt toplarken en doğru yaklaşım hangisidir?

A) Sürekli capture almak, sonra neye bakacağına karar vermek

B) Kısa ve gerekçeli zaman penceresi, minimizasyon ve kanıt manifest’i

C) Filtre kullanmamak; daha çok veri daha iyidir

D) Pcap saklamak gereksizdir; ekran görüntüsü yeter

E) Hash almak yalnızca adli olaylarda gerekir

Doğru: B
Gerekçe: Soruya yönelik kısa capture + minimizasyon + bütünlük (hash/manifest) en güvenli ve denetlenebilir yaklaşımdır.

Aşağıdakilerden hangisi “saldırı yüzeyi envanteri” için en doğru alanlardan biridir?

A) “En sevdiğimiz güvenlik ürünü”

B) “İzinli akışlar (kaynak→hedef→servis) ve kanıt kaynağı”

C) “En çok kullanılan sosyal medya uygulaması”

D) “Sadece internetten açık portlar”

E) “Sadece kullanıcı şikâyetleri”

Doğru: B
Gerekçe: Envanter akış + kontrol + kanıtı birleştirmelidir. D aşırı dar; diğerleri alakasız.

“Beklenmeyen egress” sinyali görüldü. Aşağıdaki hangi ikili, hipotezi doğrulamak/çürütmek için en dengeli başlangıçtır?

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

B) Flow özeti + değişiklik kaydı karşılaştırması

C) Sadece IDS alarmı

D) Sadece kullanıcı beyanı

E) Sadece ATT&CK etiketi

Doğru: B
Gerekçe: Flow (gözlem) + değişiklik kaydı (karşı kanıt) birlikte karar kalitesini artırır.

Risk register’da “kapanış kriteri” (closure) yoksa en büyük operasyonel sorun hangisidir?

A) Risk otomatik kapanır

B) Riskin ne zaman “azaldığı” ölçülemez; iş listesi sürünür

C) Loglar kendiliğinden artar

D) Segmentasyon otomatik iyileşir

E) Egress otomatik allowlist olur

Doğru: B
Gerekçe: Kapanış kriteri yoksa tamamlanma tanımı yoktur; risk yönetimi “sonsuz iş”e döner.

Aşağıdaki ifadelerden hangisi ATT&CK’in bu modüldeki doğru kullanımını en iyi anlatır?

A) “Teknik numarası yazarsak kanıta gerek kalmaz”

B) “ATT&CK, ortak dil ve kapsama boşluğu analizi için; kanıtla eşlenerek kullanılır”

C) “ATT&CK, saldırı adımlarını öğretmek için ana kaynaktır”

D) “ATT&CK yalnızca SOC içindir; network ekibi kullanamaz”

E) “ATT&CK kullanılırsa risk skoru hesaplanamaz”

Doğru: B
Gerekçe: Bu modülde ATT&CK, kanıt–sinyal–kontrol eşlemesi ve ortak dil içindir. A/C/D/E hatalıdır.

Kapanış: Bu modülde neler kazandın?

Ağ güvenliğini cihaz listesi değil risk temelli mimari olarak ele almayı
Tehdit–zafiyet–risk ilişkisini kanıt ve karşı kanıt mantığıyla kurmayı
Saldırı yüzeyini kategorilerle envantere dönüştürmeyi
Tehdit aktörlerini “etiket” değil davranış kalıbı olarak kullanmayı
Defense-in-depth, least privilege, management plane ayrımı gibi ilkeleri operasyonel karara çevirmeyi
MITRE ATT&CK’i “checklist” değil ortak dil ve kapsama analizi için kullanmayı
Risk Register + Saldırı Yüzeyi Envanteri’ni runbook disiplininde üretmeyi

MODÜL 2 — Network Tehditleri: Mekanizma, Etki, Tespit Sinyalleri

Kavramsal şema: uçlar arası tehdit mekanizması, bırakılan sinyaller ve belirti → hipotez → kanıt → karar triage hattı.

Bu modül, tehditleri “isim isim ezberleme” yerine, ağ üzerinde hangi mekanizma ne tür iz (sinyal) bırakır? sorusuna odaklanır. MitM/eavesdropping, spoofing, DoS/DDoS, AI-destekli tehdit eğilimleri ve kablosuz tehditleri savunma perspektifinden ele alır: amaç saldırı öğretmek değil; belirti → hipotez → kanıt → karar döngüsüyle hızlı ve güvenli triage yapabilmektir. Her başlıkta “ne anlama gelir, etkisi nedir, nerede sinyal bırakır, hangi kontrolle azaltılır” sorularını aynı disiplinle yürütürsün. Modül sonunda elinde, “hangi tehdit için hangi veri kaynağına bakarım ve ilk ne yaparım?” sorusunu yanıtlayan Sinyal Haritası bulunur; bu çıktı sonraki modüllerde kontrol tasarımı ve tuning çalışmalarına doğrudan girdi olur.

Bu Dersin Hedefleri

MitM / eavesdropping davranışlarını, ağ katmanlarında bıraktığı sinyaller üzerinden tanımlamak.
IP/MAC/ARP/DNS spoofing türlerini mekanizma ve kanıt kaynaklarıyla ayırt etmek.
DoS/DDoS etkisini “boğaz nerede?” sorusuna indirgeme refleksi kazanmak; erken uyarı sinyallerini doğru okumak.
AI-destekli ağ tehditlerini kanıt–yorum ayrımını koruyarak kavramsal düzeyde değerlendirmek.
Kablosuz tehditleri cracking öğretmeden, kurumsal risk yönetimi ve tespit sinyalleriyle ele almak.
Threat → Veri Kaynağı → İlk Aksiyon eşlemesiyle Sinyal Haritası üretmek ve kanıt disiplinine bağlamak.

2.1 MitM / Eavesdropping (savunma odaklı)

Kavram	Tanım (savunma odağı)
Eavesdropping (dinleme)	Trafiğin içeriğinin yetkisiz biçimde okunması/izlenmesi. Şifrelenmemiş protokoller veya yanlış/zayıf şifreleme nedeniyle mümkün hâle gelebilir.
MitM / AiTM	İki uç arasındaki iletişime araya girilerek müdahale; her zaman “içerik değiştirme” şart değildir. Savunmada kritik nokta, trafik yolunu, DNS çözümlemesini veya L2/L3 eşleşmelerini etkilerken iz bırakmasıdır. (ATT&CK’ta “Adversary-in-the-Middle” bu sınıfı kapsar.)

Etki / risk

Boyut	Olası sonuç
Gizlilik	Oturum belirteçleri, kimlik bilgileri, iş verisi açığa çıkabilir.
Bütünlük	Trafik manipülasyonu, yanlış yönlendirme ve hatalı iş kararları.
Erişilebilirlik	Hatalı araya girme veya yanlış yapılandırma nedeniyle bağlantı kopmaları.
Operasyonel	“Sertifika uyarısı” gibi belirtiler meşru değişikliklerle (yenileme, CDN rotasyonu) karışabilir; yanlış containment kesintiyi büyütür.

Tespit sinyali / kanıt

Sinyal grubu	Ne tararsın? (özet)
TLS	Kullanıcı şikâyetleri (“sertifika uyarısı”, “sertifika değişti” — tek başına kanıt değil; korelasyon gerekir). PCAP’te el sıkışması hataları, SNI ile sertifika zinciri tutarsızlığı (yalnızca izinli, kısa pencere, veri minimizasyonuyla).
DNS	Aynı alan adının kısa aralıklarla farklı IP’lere çözülmesi (meşru sebepler olabilir; karşı kanıt şart). Beklenmedik resolver değişimi; NXDOMAIN oranında anomali.
L2 / L3	ARP/neighbor tablolarında gateway eşleşmesinin hızlı değişimi; gratuitous ARP yoğunluğu. Switch tarafında MAC hareketliliği / CAM “flapping” benzeri işaretler (ortama göre).

Dikkat: MitM şüphesinde “kim yaptı?” yerine “ne gördük?” diye başla. Etiket, kanıt değildir.

İpucu: En hızlı triage: belirti tek kullanıcıda mı, bir segmentte mi, tüm kurumda mı? Kapsam sinyali kök neden sınıfını hızla daraltır.

Savunma kontrolü / düzeltme yaklaşımı

Kontrol çizgisi	Operasyonel hedef
Şifreleme hijyeni	Şifresiz protokolleri kaldırmak; TLS duruşunu doğru kurmak (bu modülde neden/sinyal düzeyinde).
Görünürlük	DNS loglama; kritik segmentlerde flow; olay anında kısa süreli PCAP üretebilme.
L2 tutarlılık	IP/MAC eşleşmesi ve anomali alarmlarıyla tutarsız eşleşmeleri zorlaştırmak.
Karşı kanıt	Sertifika değişiminde önce planlı yenileme, rota/CDN değişimi gibi meşru nedenleri elemek.

2.2 Spoofing (IP/MAC/ARP/DNS)

Spoofing; IP, MAC, ARP veya DNS gibi kimlik/yer bilgisinin sahte gösterilmesidir. Savunmada hedef “nasıl yapılır?” öğrenmek değil; tutarsızlıkları kanıtla yakalamaktır.

Tür	Özet
IP spoofing	Kaynak IP’nin sahte gösterilmesi.
MAC spoofing	Cihazın L2 kimliğinin sahte gösterilmesi.
ARP spoofing / cache poisoning	IP↔MAC eşleşmelerinin yanıltılması (ATT&CK “ARP cache poisoning” bu davranışı kapsar).
DNS spoofing / redirect	Alan adı çözümlemesinin yanlış hedefe yönlendirilmesi.

Etki / risk

Başlık	Açıklama
İz sürmek	“Kim konuştu?” sorusu zorlaşır.
Yetkisiz erişim görünümü	Denemeler daha “meşru” görünebilir (zayıf segmentasyon/izlemede).
DNS	Yanlış yönlendirme; MitM/eavesdropping riskini büyütür.
Operasyonel	IP/MAC değişimi çoğu zaman meşrudur (DHCP, cihaz değişimi, sanallaştırma); alarm yorgunluğu tetiklenebilir.

Tespit sinyali / kanıt

Grup	Örnek gözlemler
IP/MAC tutarsızlığı	DHCP’de aynı IP’ye farklı MAC; aynı MAC’in beklenmedik segmentlerde görünmesi. ARP/neighbor’da hızlı değişim; gateway MAC’inin beklenmedik şekilde değişmesi (yüksek öncelikli süreç sinyali).
ARP	Kısa pencerede yoğun ARP trafiği. Wireshark’ta `arp.duplicate-address-detected` / `arp.duplicate-address-frame` ile duplicate IP işaretleri (hızlı tarama).
DNS	FQDN’in kısa TTL ile farklı hedeflere dönmesi (tek başına kanıt değil). Resolver veya upstream DNS değişimi. Proxy + DNS + flow ile yeni domain, yeni IP ve egress artışının birlikte görülmesi.
Ağ cihazı	IP conflict uyarıları; port bazlı MAC “zıplaması” (ortama göre).

Dikkat: “Gateway MAC değişti” tek başına spoofing değildir; failover, cihaz değişimi veya sanallaştırma da aynı görüntüyü verebilir.

İpucu: İddia üçlü korelasyon ister: L2 anomali, DNS/flow ile uyum ve (varsa) değişiklik kaydıyla çelişki.

Savunma kontrolü / düzeltme yaklaşımı

Önlem	Ne kazanırsın?
L2 tutarlılık	IP/MAC bağlama, ARP doğrulama, port güvenliği ile sahte eşleşme üretimini zorlaştırma.
DNS görünürlüğü	Standart resolver, log ve değişiklik disiplini.
Segmentasyon / egress	Spoofing olsa bile etki alanını daraltma.
Raporlama	“ARP değişti” yerine: hangi cihaz, hangi IP, ne zaman, hangi karşı kanıt.

Bypass / erişim farkındalığı (savunma formatı). Kategori: ARP/DNS tutarsızlığı. Amaç (kavramsal): trafik yönünü etkilemek. Beklenen sinyal: gateway MAC değişimi ile DNS’te beklenmeyen hedef. Kontroller: L2 tutarlılık, DNS logging, segmentasyon.

Örnek kanıt cümlesi (uydurma): “198.51.100.1 gateway MAC’i 10 dakika içinde iki kez değişti; aynı aralıkta portal.example.com farklı IP’ye çözüldü.”

2.3 DoS/DDoS (savunma perspektifi)

DoS

Servis veya ağ bileşenini kaynak tüketerek kullanılamaz kılmaya yönelik etki.

DDoS

Aynı etkinin birçok kaynaktan ölçeklenmesi.

Savunmada “trafik arttı” cümlesini boğaz nerede? sorusuna çevir: hat mı, CPU mu, state tablosu mu, uygulama havuzu mu, upstream mi? ATT&CK’ta bu etki sınıfı “Network Denial of Service” ile ilişkilendirilir.

Etki / risk

Boyut	Sonuç
Erişilebilirlik	Kesinti, SLA riski, gelir ve itibar kaybı.
İkincil	Yük altında log azalması veya drop davranışı değişimi; görünürlük kaybı.
Panik	Geniş bloklar müşteri kesintisini büyütebilir.

Tespit sinyali / kanıt

Kaynak	Tipik işaretler
Ağ	Link doygunluğu, ani PPS, latency/jitter sıçraması.
Flow	Tek hedefe veya servise yoğunlaşma; belirli portlarda yığılma.
Cihaz	FW/LB CPU, state/connection doluluğu, SYN benzeri yarım bağlantı göstergeleri (gözlem düzeyinde).
Servis	Uzayan yanıt süreleri, 5xx, health check hatası.

İpucu (kanıt üçlüsü): İddia tek grafikle değil; flow yoğunluğu + cihaz metriği + servis etkisi ile sabitlenir.

Savunma kontrolü / düzeltme yaklaşımı

İlke	Uygulama
Katmanlı savunma	Upstream temizleme, rate limit, kapasite, kritik servis ayrıştırma.
Do not harm	İlk hamle geniş blok değil; kapsam ve kanıt.
Korelasyon	Flow, metrik ve health birlikte yoksa “DDoS kesin” deme.
Karşı kanıt	Kampanya, yedekleme veya iş trafiği artışı olabilir; plan kontrolü.

2.4 AI-destekli ağ tehditlerine giriş (kavramsal)

“Tamamen yeni bir tür”den çok, bilinen yöntemlerin hızlanması ve ölçeklenmesi görülür. Ağda sık karşılaşılan yansımalar üç ana grupta toplanabilir:

Hedefleme

Daha az ama daha isabetli şüpheli akışlar.

Kamuflaj

Normal benzeri zamanlama ve yoğunluk; anomali ayrımını zorlaştırır.

Savunma yanıltma

Yanlış pozitif/negatif; alarm yorgunluğu veya kör nokta.

Etki / risk

Triage maliyeti artar; “AI yaptı” etiketi kanıt değildir. ML/NDR kullanılıyorsa veri kalitesi, log bütünlüğü ve model drift (bu modülde yalnızca kavramsal) kritikleşir.

Tespit sinyali / kanıt

Odak	Örüntü
Egress	Az hacimli ama hedefli bağlantılar; yeni veya seyrek domain’ler.
Zamanlama	Patlama yerine düşük yoğunlukta uzun süreli hareket.
Alarm tabanı	IDS/NDR dağılımında ani değişim: ya kalitesiz alarm seli ya da olağandışı sessizlik.

Savunma kontrolü / düzeltme yaklaşımı

Kanıt standardını DNS + proxy + flow ile yükselt; “ilk kez görülen” varlıkları envanterle eşle. Model varsa veri sürekliliği ve drift gözlemi hijyen ister. Rapor dilinde: “Davranış X gözlendi; Y ile uyumlu; Z belirsiz.”

Dikkat: AI konuşulurken en sık hata, kanıtı aşan genellemedir.

İpucu: “Davranış X, Y ile uyumlu; ancak Z karşı kanıtı dışlanmadan kesin atıf yapılmadı.” cümle yapısını kullan.

2.5 Kablosuz tehditler (cracking öğretmeden)

Kablosuz risk yalnızca “şifre kırma” değildir. Kurumsal sahnede sık görülen kökler: rogue AP (envanter dışı yayın), evil twin (meşru SSID’yi taklit), yanlış SSID ve segment tasarımı, zayıf misafir izolasyonu ve yönetim arayüzlerinin hatalı konumu.

Etki / risk

Konu	Risk
Lateral hareket	Kablosuzdan iç ağa yanlış köprüleme.
Kimlik / güven	Sahte SSID’ye bağlanma ve yönlendirme.
Operasyon	Kapsama veya RF kaynaklı sorunlar güvenlik sanılabilir; kanıt şart.

Tespit sinyali / kanıt

Kaynak	Ne ararsın?
Controller / WIDS	Yeni veya beklenmeyen BSSID; aynı SSID altında farklı BSSID; şifreleme profili uyumsuzluğu. Deauth/disassoc artışı (performans da neden olabilir).
RADIUS / kimlik	Auth başarısızlık artışı; beklenmedik cihaz türü veya konum.
İstemci	“Portal değişti”, “sertifika uyarısı” (tek başına kanıt değil).
Kanıt paketi	Controller olay kesiti, istemci bağlantı geçmişi, gerekirse kısa ve izinli gözlem çıktısı.

Savunma kontrolü / düzeltme yaklaşımı

Kurumsal ve konuk SSID ayrımı, segmentasyon, rogue süreçleri ve güçlü kimlik/duruş (detay sonraki modüllerde) sinyal düzeyinde hatırlanır. Kullanıcıya “güvenlik mi, kapsama mı?” ayrımı için kısa doğrulama ve kayıt disiplini uygulanır.

Bypass / erişim farkındalığı. Rogue / evil twin: kullanıcıyı sahte erişim noktasına çekme (kavramsal). Sinyal: aynı SSID altında yeni BSSID, auth hataları, ani roaming. Kontroller: controller/WIDS, SSID-BSSID allowlist, kullanıcı bilgilendirmesi.

Örnek (uydurma): “CorpWiFi için beklenmeyen BSSID ilk kez görüldü; 10 dakikada 20 istemci yeniden kimlik doğrulamaya zorlandı.”

2.6 HOW-TO: “Sinyal Haritası” (Threat → Veri Kaynağı → İlk Aksiyon)

Sinyal Haritası, her tehdit için “hangi kaynağa bakarım, ilk ne yaparım?” sorusuna tek tip yanıt verir. Böylece rastgele veri toplamak yerine hedefli triage yapılır; örneğin DNS log yoksa DNS iddiasının gücü düşer ve bu görünürlük açığı kayda geçer. Harita aynı zamanda sonraki modüllerde kontrol tasarımına girdi verir, yeni konu açmadan köprü kurar.

Hız

Panik yerine net veri toplama.

Görünürlük

Eksik log ve sensörleri görünür kılar.

Tasarım girdisi

Kontrol ve kanıt önceliklerine yön verir.

2.7 Komut & Araç Okuryazarlığı (denetim / doğrulama / kanıt)

Aşağıdaki komutlar yalnızca izinli ve yerel kullanım içindir. Amaç saldırı üretmek değil; hipotezi doğrulamak veya çürütmek ve denetlenebilir kanıt üretmektir.

Ortak kanıt disiplini

(1) Zaman damgası al → (2) çıktıyı dosyala → (3) hash üret → (4) hangi hipotezi test ettiğini notla. PCAP yalnızca gerekliyse; 60–180 saniye, dar filtre, minimizasyon.

Windows (PowerShell / yerel doğrulama)

Adım	Komut	Amaç / yorum	Sınır
Zaman	`Get-Date -Format o \| Out-File .\evidence\time_local_iso8601.txt`	Tüm kanıtları tek zaman eksenine bağla.	Okuma
DNS	`Get-DnsClientServerAddress \| Out-File .\evidence\dns_servers.txt`	Resolver değişti mi? (DNS spoofing hipotezi). Beklenmeyen değer önce “planlı mı?” kontrolü ister.	Okuma
ARP	`arp -a > .\evidence\arp_table.txt`	Gateway ve kritik IP’lerin IP↔MAC eşleşmesi; değişim örüntüsü.	Okuma
Bağlantı	`Get-NetTCPConnection \| Select-Object State,LocalAddress,LocalPort,RemoteAddress,RemotePort \| Out-File .\evidence\tcp_connections.txt`	Aşırı bağlantı var mı? Zaman penceresiyle ilişkilendir.	Okuma
PCAP	`pktmon start --capture --comp nics --pkt-size 0`	Kısa ham yakalama; Wireshark ile okuma için. Gerekçe ve süre notu şart.	İzinli, kısa
Hash	`Get-FileHash .\evidence\arp_table.txt -Algorithm SHA256`	Dosya bütünlüğü; manifest’e ekle.	Okuma

Windows PowerShell — denetim çıktısı (örnek)

PS C:\evidence> Get-Date -Format o 2026-04-16T14:42:18.3319042+03:00 PS C:\evidence> Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object -First 2 InterfaceAlias, ServerAddresses InterfaceAlias ServerAddresses Ethernet 2 {192.0.2.53, 192.0.2.1} Wi-Fi {192.0.2.53} PS C:\evidence> arp -a | Select-String "192.0.2.1" 192.0.2.1 00-11-22-33-44-55 dynamic PS C:\evidence> Get-FileHash .\arp_table.txt -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 A3F...C91 .\arp_table.txt /* Örnek metindir; IP/MAC/hash değerleri ortamınıza göre değişir. */

Linux (yerel doğrulama)

Adım	Komut	Amaç / yorum	Sınır
UTC zaman	`date -u +"%Y-%m-%dT%H:%M:%SZ" \| tee evidence/time_utc.txt`	Çoklu kanıtı UTC ile hizala.	Okuma
DNS	`resolvectl status \| tee evidence/dns_status.txt`	Resolver ve arayüz; beklenmeyen değişiklikte standart kontrolü.	Okuma
Komşu	`ip neigh \| tee evidence/neigh_table.txt`	IP–MAC komşuluk; gateway hareketi.	Okuma
Oturum	`ss -s \| tee evidence/socket_summary.txt`	DoS etkisine dair özet; ani artış sinyal olabilir.	Okuma
PCAP	`tcpdump -i <iface> -w evidence/capture_120s.pcap -G 120 -W 1 '(arp) or (udp port 53) or (tcp port 443)'`	ARP/DNS/TLS çevresinde kısa kanıt.	İzinli, kısa
Manifest	`sha256sum evidence/* \| tee evidence/manifest.sha256`	Paket bütünlüğü.	Okuma

bash — evidence klasörü (örnek)

analist@ws:~/evidence$ date -u +"%Y-%m-%dT%H:%M:%SZ" 2026-04-16T11:42:18Z analist@ws:~/evidence$ resolvectl status | head -n 12 Global DNS Domain: example.corp DNS Servers: 192.0.2.53 192.0.2.1 analist@ws:~/evidence$ ip neigh | grep -E '192\.0\.2\.1|FAILED' 192.0.2.1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE analist@ws:~/evidence$ sha256sum arp_table.txt neigh_table.txt a3f...c91 arp_table.txt 7e2...9bb neigh_table.txt # Çıktılar örnektir; çözümleyici ve komşu tabloları kurumunuza göre değişir.

macOS (yerel doğrulama)

Adım	Komut	Amaç / yorum	Sınır
UTC zaman	`date -u +"%Y-%m-%dT%H:%M:%SZ" \| tee evidence/time_utc.txt`	Kanıt zaman çizgisi.	Okuma
DNS	`scutil --dns \| head -n 120 > evidence/dns_status.txt`	Resolver sırası ve eşleşme.	Okuma
ARP	`arp -a > evidence/arp_table.txt`	IP–MAC eşleşmeleri.	Okuma
İstatistik	`netstat -s \| head -n 80 > evidence/netstat_stats.txt`	Yük ve hata sinyallerine hızlı bakış.	Okuma
PCAP	`tcpdump -i <iface> -w evidence/capture_120s.pcap -G 120 -W 1 '(arp) or (udp port 53) or (tcp port 443)'`	Hipotez için kısa dosya.	İzinli, kısa
Manifest	`shasum -a 256 evidence/* \| tee evidence/manifest.sha256`	Hash listesi.	Okuma

Terminal — zsh (örnek)

analist@MacBook evidence % date -u +"%Y-%m-%dT%H:%M:%SZ" 2026-04-16T11:42:18Z analist@MacBook evidence % scutil --dns | head -n 14 DNS configuration resolver #1 nameserver[0] : 192.0.2.53 nameserver[1] : 192.0.2.1 analist@MacBook evidence % arp -a | grep '192.0.2.1' ? (192.0.2.1) at 0:11:22:33:44:55 on en0 ifscope [ethernet] analist@MacBook evidence % shasum -a 256 arp_table.txt | tee -a manifest.sha256 a3f29c...91e8 arp_table.txt # Örnek metindir; arayüz adı ve çıktı biçimi sürüme göre değişebilir.

Wireshark / tshark — hipotez odaklı okuma

Nereden başlarım? Önce soruyu yaz: “DNS yönlendirme sinyali var mı?”, “Gateway MAC dalgalanıyor mu?” Yakalama kısa (60–180 sn); ring buffer ile küçük dosyalar. Gerekçe ve minimizasyon notu kanıt paketine eklenir.

Nasıl okurum? Statistics → Endpoints ve Conversations; Analyze → Expert Information; Follow Stream yalnız gerektiğinde (hassas veri riski). Filtre örnekleri: arp; arp.duplicate-address-detected / arp.duplicate-address-frame; dns; SYN başlatma yoğunluğu; tek IP odaklı ip.addr. Kanıt: CSV dışa aktarma, PCAP hash, hipotez notu; rapor dili Bulgu → Etki → Öneri → Kanıt.

Örnek: tshark metin oturumu

GUI yerine dosya üzerinden okuduğunda çıkan özet metin; hipotezi destekleyen satırları rapora aktarmak için kullanılır (kavramsal örnek).

tshark — kayıtlı PCAP üzerinde okuma (örnek)

analist@ws:~/evidence$ tshark -r capture_120s.pcap -q -z conv,ip -c 0 ================================================================================ IPv4 Conversations Filter:<No Filter> | Frames | Bytes | 192.0.2.10 <-> 192.0.2.1 1240 612888 192.0.2.10 <-> 203.0.113.30 8420 4012000 ================================================================================ analist@ws:~/evidence$ tshark -r capture_120s.pcap -Y "dns.flags.response == 0" -T fields -e frame.time -e dns.qry.name | head -n 5 Apr 16, 2026 14:42:01.112 portal.example.corp. Apr 16, 2026 14:42:01.118 cdn.assets.example.net. # Aynı dosya için: sha256sum veya Get-FileHash ile hash kaydı manifest’e eklenir.

2.8 HOW-TO — “Sinyal Haritası” Üretimi (Threat → Veri Kaynağı → İlk Aksiyon)

Hazırlık

Kapsamı tek seferde şişirme: edge mi, iç segment mi, kablosuz mu? Veri kaynaklarını var / yok diye yaz: DNS, DHCP, FW/proxy, flow, PCAP (gerekirse), Wi-Fi controller/WIDS, cihaz metrikleri ve servis health. Kanıt standardı: zaman damgası + dosya + hash manifest + kısa not.

Uygulama — yaşayan harita tablosu

Tehdit (özet)	Tipik sinyal	Birincil kaynak	İkincil	İlk güvenli aksiyon
MitM / eavesdropping	TLS hata artışı, sertifika şikâyeti, DNS tutarsızlığı	DNS log + kısa PCAP	Proxy / flow	Zaman penceresi; planlı değişiklik kontrolü; minimum PCAP + hash
ARP spoofing şüphesi	Gateway MAC değişimi, ARP yoğunluğu, duplicate IP	ARP/neigh + switch log	Kısa PCAP (arp)	Kapsam ölç; DHCP/cihaz karşı kanıtı
DNS şüphesi	FQDN→IP oynaklığı, resolver değişimi	İstemci resolver + DNS log	Proxy + flow	Resolver standardı; korelasyon; kesin atıftan kaçın
DoS/DDoS etkisi	PPS/latency, health düşüşü	Flow + cihaz	PCAP	Meşru trafik karşı kanıtı; üçlü sabitleme
AI eğilimi şüphesi	Düşük hacimli egress, alarm dağılımı	DNS+proxy+flow	NDR	Uyumlu sinyal dili; tuning notu
Rogue / evil twin	Yeni BSSID, auth hatası, roaming	Controller/WIDS	İstemci	Allowlist kıyası; log kesiti

Doğrulama sütunları

Her satıra doğrulayan kanıt (hangi log alanı?) ve çürüten / alternatif (bakım, CDN, cihaz yenilemesi vb.) alanlarını ekle. “Veri kaynağı yok” satırlarını işaretle: bu çoğu zaman görünürlük açığıdır, yalnızca “kontrol yok” demek değildir.

Kanıt paketi

Harita dosyası (YYYYMMDD_mod2_signalmap_v1.csv), evidence/ altında kesitler, manifest.sha256. Raporda Kanıt bölümüne manifest referansı ver.

Geri dönüş / rollback

Yanlış pozitifte haritadaki sinyal tanımını ve karşı kanıt alanını güncelle. Fazla veride minimizasyon ve güvenli silme notu. Şablon değiştiyse sürüm + değişiklik kaydı tut.

2.9 Operasyonel Senaryo — “Yavaşlık + Sertifika Uyarısı: MitM mi, Meşru Değişiklik mi?”

Belirti

198.51.100.0/24 segmentinde kısa süreli yavaşlık ve ara sıra “güvenli bağlantı uyarısı” şikâyetleri var. Aynı pencerede DNS’te portal.example.com çözümlerinde oynaklık izleniyor gibi. Bu gözlemdir; hüküm değildir.

Hipotezler (önceliklendir)

#	Hipotez
1	Planlı değişiklik: gateway failover veya cihaz değişimi → meşru MAC hareketi.
2	L2 tutarsızlık: ARP/neighbor anomalisi (ARP cache poisoning ile uyumlu olabilir).
3	Meşru DNS/CDN rotasyonu: TTL ve yanıt değişimi.
4	Performans/kapsama + yanlış güvenlik yorumu.

Minimum kanıt seti (izinli)

Kaynak	Ne toplanır?
İstemci	ARP/neighbor çıktısı (hash’li); resolver yapılandırması (hash’li).
İstemci (gerekirse)	120 sn PCAP: arp + dns + 443, hash’li.
Altyapı	DNS log kesiti, zaman penceresi sınırlı, hash’li.
Karşı kanıt	Değişiklik kaydı / bakım penceresi (varsa).

Örnek adresler (uydurma): istemci 198.51.100.20, gateway 198.51.100.1, DNS 198.51.100.53.

Analiz akışı

Kapsamı ölç (kullanıcı mı, segment mi?) ve zaman çizelgesi çıkar. Gateway için MAC değişimi var mı, kaç kez? Resolver standart mı? portal.example.com için TTL/rotasyon meşru mü? PCAP’ta arp ve gerekiyorsa duplicate IP işaretleri var mı (misconfig ile de uyumlu olabilir)? Aynı saatlerde failover veya DNS planı var mı?

Karar ve rapor

Güçlü planlı değişiklik kanıtı varsa olayı “operasyonel değişim + kullanıcı etkisi” olarak kaydet; Sinyal Haritası’na karşı kanıt örneği ekle. L2/DNS tutarsızlığı süer ve meşru açıklama zayıfsa kapsamı kontrollü genişlet; L2 tutarlılık, DNS standardı ve görünürlük önerilerini yaz. Her durumda manifest tamamla; belirsizlikleri dürüstçe belirt.

Rapor iskelesi (Bulgu → Etki → Öneri → Kanıt)

Bulgu: segmentte yavaşlık ve DNS oynaklığı gözlemleri; gateway eşleşmesinde değişim (kanıta göre var/yok). Etki: tutarsızlık meşru değilse trafik güvenilirliği riski; meşru değişiklikse iletişim/kayıt eksikliği kullanıcıyı büyütmüştür. Öneri: değişiklik korelasyonu, resolver doğrulama, L2 gözden geçirme, haritada karşı kanıt alanı. Kanıt: ARP/neighbor, resolver, DNS log, PCAP (hash’li), manifest.

Terimler Sözlüğü

Terim	Açıklama
MitM / Adversary-in-the-Middle	İletişime araya girme; savunmada sinyal ve kanıt odağı.
Eavesdropping	Trafiğin yetkisiz izlenmesi.
Spoofing	Kimlik veya yer bilgisinin sahte gösterilmesi.
ARP cache poisoning	IP↔MAC eşlemesinin yanıltılması.
DNS spoofing / redirect	Yanlış IP’ye çözüm veya yönlendirme.
DoS / DDoS	Hizmeti kullanılamaz kılma etkisi; tekil veya dağıtık kaynak.
Network Denial of Service	Ağ seviyesinde kesinti etkisi (sınıf).
Flow (NetFlow/IPFIX)	Özet trafik kayıtları; kanıt kaynağı.
PCAP	Ham yakalama; kısa süre ve minimizasyon.
TTL	DNS’te yaşam süresi; rotasyonla karışabilir.
Rogue AP	Envanter dışı kablosuz erişim.
Evil Twin	Meşru SSID taklidi; sinyal odaklı ele alınır.
WIDS/WIPS	Kablosuz tespit/önleme (log kaynağı).
“Uyumlu sinyal”	Kesin hüküm yerine kanıtla uyumlu, temkinli ifade.

Kendini Değerlendir

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

Aşağıdakilerden hangisi, “MitM şüphesi” için en güçlü kanıt kombinasyonu yaklaşımını temsil eder?

A) Tek bir kullanıcıda sertifika uyarısı + tek seferlik DNS çözümleme değişimi

B) Sertifika uyarısı + DNS loglarında resolver değişimi + aynı zaman penceresinde kısa PCAP’te TLS el sıkışma anomali işaretleri

C) DNS TTL değerinin düşmesi + ağ gecikmesinin artması

D) ARP tablosunda tek satır değişimi + kullanıcı şikâyeti yok

E) Sadece “yavaşlık” şikâyeti + CPU grafiğinde anlık yükseliş

Doğru: B
Gerekçe: B, çoklu kaynaktan korelasyon (istemci belirti + DNS yapılandırma/log + PCAP sinyali) sağlar. A/C tekil ve meşru sebeplerle karışabilir. D bağlam/karşı kanıt yok. E tehdit sınıfını ayırt ettirmez.

“Gateway MAC değişti” sinyalini gördün. “Do not harm” ilkesine en uygun ilk aksiyon hangisi?

A) Hemen geniş kapsamlı bloklar uygulamak

B) Kısa zaman penceresi belirleyip ARP/neighbor çıktısını ve DNS resolver bilgisini kanıt olarak paketlemek; planlı değişiklik karşı kanıtını kontrol etmek

C) Tüm istemcilerde ağ ayarlarını sıfırlamak

D) Segmenti tamamen kapatmak

E) “Spoofing kesin” diyerek olayı rapora saldırı olarak yazmak

Doğru: B
Gerekçe: B, kapsamı dar tutar, kanıt üretir ve karşı kanıt arar. A/D gereksiz kesinti riski taşır. C orantısızdır. E kanıt–yorum ayrımını bozar.

ARP spoofing şüphesinde “birincil veri kaynağı” seçimi için en doğru yaklaşım hangisi?

A) Sadece uygulama logları

B) ARP/neighbor tablosu + (varsa) switch tarafı MAC hareketliliği / ilgili olay logları

C) Sadece proxy logları

D) Sadece IDS imzaları

E) Yalnızca kullanıcı şikâyetleri

Doğru: B
Gerekçe: ARP spoofing L2/L3 eşleşme problemidir; ARP/neighbor ve (varsa) switch sinyali birincildir. Diğerleri yardımcı olabilir ama tek başına zayıftır.

DoS/DDoS triage’ında “kanıt üçlüsü” en iyi hangi seçenekle özetlenir?

A) DNS TTL + sertifika uyarısı + ARP tablosu

B) Flow yoğunluğu + cihaz kaynak metriği + servis etkisi (health/5xx/latency)

C) Tek bir PCAP + tek bir grafik + tek bir kullanıcı şikâyeti

D) Sadece CPU grafiği

E) Sadece link kullanım grafiği

Doğru: B
Gerekçe: B, etkiyi ağ + cihaz + servis düzleminde doğrular. C zayıf korelasyon. D/E tek boyutludur.

AI-destekli tehdit şüphesini raporda kanıtı aşmadan yazmanın en doğru yolu hangisi?

A) “AI saldırısı tespit edildi, kesin.”

B) “Davranış X gözlendi; Y ile uyumlu; ancak Z karşı kanıtı dışlanmadan kesin atıf yapılmadı.”

C) “Saldırgan şu aracı kullanmıştır.”

D) “AI olduğu için tespit edilemez.”

E) “Bu trafik normaldir.”

Doğru: B
Gerekçe: B, uyumlu sinyal + belirsizlik disiplinini korur. A/C kanıtı aşar. D genelleme. E kanıt sunmaz.

Kablosuz “evil twin” riskinde en anlamlı sinyal seti hangisidir?

A) Yalnızca DNS TTL değişimi

B) Aynı SSID’nin yeni/beklenmeyen BSSID ile belirmesi + auth hata artışı + istemci roaming anomalisi

C) Firewall CPU artışı

D) Sadece kullanıcı “yavaş” şikâyeti

E) Tek bir paket kaybı grafiği

Doğru: B
Gerekçe: B, evil twin/rogue senaryosuna özgü controller/istemci sinyallerini birleştirir. Diğerleri özgül değildir.

Wireshark’ta “duplicate IP” sinyallerini hızlı taramak için uygun yaklaşım hangisidir?

A) tcp.flags.syn==1 && tcp.flags.ack==0 filtresi

B) arp.duplicate-address-detected ve/veya arp.duplicate-address-frame ile tarama; sonuçları misconfig olasılığıyla birlikte yorumlama

C) Sadece “Follow Stream” ile tüm trafiği okumak

D) Hiç filtre kullanmadan tüm PCAP’i baştan sona incelemek

E) “Duplicate IP varsa kesin spoofing” diye karar vermek

Doğru: B
Gerekçe: B hem doğru filtreleme refleksini hem de tek sinyalin kesin hüküm olmadığını vurgular. A farklı amaç. C/D verimsiz ve riskli. E kanıt–yorum ayrımını bozar.

Sinyal Haritasında “görünürlük açığı” en net hangi durumla anlaşılır?

A) Tehdit satırında tipik sinyal yazmaması

B) Birincil/ikincil veri kaynaklarının “yok” olması ve iddianın buna rağmen kesin yazılması

C) İlk aksiyonun “kanıt paketle” olması

D) Karşı kanıt alanının dolu olması

E) Harita dosyasına sürüm numarası eklenmesi

Doğru: B
Gerekçe: Veri kaynağı yokken kesin iddia, görünürlük açığı ve raporlama hatasıdır. Diğerleri görünürlük açığı göstermez.

Kanıt paketleme adımlarının doğru sıralaması hangisidir?

A) Hash → çıktı al → zaman damgası → not yaz

B) Çıktı al → zaman damgası → hash → not yaz

C) Zaman damgası → çıktı al → hash → hipotez notu

D) Not yaz → hash → zaman damgası → çıktı al

E) Zaman damgası → hash → çıktı al → not yaz

Doğru: C
Gerekçe: Zaman damgası önce alınır; ardından çıktı üretilir; sonra bütünlük için hash; en son “hangi hipotezi test ediyor?” notu ile bağlama oturtulur.

DNS spoofing iddiasını çürütebilecek en güçlü karşı kanıt örneği hangisidir?

A) Tek bir kullanıcı “site açılmadı” dedi

B) Aynı FQDN’in farklı IP’lere dönmesi

C) Değişiklik kaydında aynı zaman penceresinde CDN/altyapı rotasyonu ve sertifika yenilemesi planlı olarak kayıtlı; resolver standardı değişmemiş

D) Wi-Fi sinyali zayıf

E) CPU grafiği normal

Doğru: C
Gerekçe: C, meşru değişiklik ve standartla uyumu belgeleyerek iddiayı zayıflatır. B tek başına kanıt değildir. A/D/E alakasız veya zayıf.

Kapanış: bu modülde neler öğrendin?

Sinyal & triage

MitM şüphesini TLS, DNS ve L2 kanıtlarıyla yaklaşmak; tek belirtiye dayanmamak.

Spoofing & DoS

Spoofing türlerini kaynaklara göre ayırt etmek; DoS/DDoS’ta “boğaz nerede?” ve üçlü korelasyon.

AI & kablosuz

AI eğilimlerini davranış ve belirsizlik diliyle yazmak; kablosuzda kurumsal log ve kanıt disiplini.

Sinyal Haritası

Tehdit → veri kaynağı → ilk aksiyon eşlemesi ve kanıt paketleme.

MODÜL 3 — Güvenlik Kontrolleri I: Firewall, ACL, Proxy, IDS/IPS + SASE/SSE

Kavramsal şema: dış trafiğin firewall ve ACL ile süzülmesi, proxy üzerinden uygulama yolu, IDS/IPS ile izleme veya engelleme; SASE/SSE ise aynı kontrol düzenini buluta/kenara yayar.

Kısa giriş ve çerçeve

Ağ güvenliğini “tek bir cihaz” değil, uçtan uca bir kontrol zinciri olarak düşün: sınırı firewall/ACL ile çiz, web erişimini proxy/SWG ile yönet, görünürlük ve tespiti IDS/IPS/NDR ile güçlendir, dağıtık kullanıcı/şube/bulut gerçekliğinde bu tutarlılığı SASE/SSE yaklaşımıyla koru. Bu modülün odağı “kural yazmayı bilmek”ten çok, kuralın niyetini, etkisini ve kanıtını yönetmektir: yanlış pozitif yormayan, yanlış negatif bırakmayan, değişiklik kaydı ve geri dönüş (rollback) planı olan, raporlanabilir bir operasyon disiplini.

Bu modülde “saldırıyı nasıl yaparım?” yok. Bunun yerine şu soruyu runbook mantığıyla ele alacağız:

“Bu kontrol gerçekten doğru çalışıyor mu; hangi log/flow/PCAP bunu doğrular veya çürütür?”

Bu Dersin Hedefleri

Firewall/ACL türlerini, default deny ve en az yetki (least privilege) ilkeleriyle politika mantığına bağlayabilmek.
Kural tasarımında sıralama (first match), gölgeleme (shadowing), scope ve sahiplik/süre disiplinini denetlenebilir şekilde uygulayabilmek.
Proxy/SWG’de kimlik temelli politika, kategori/URL kararları, TLS hataları ve log korelasyonunu operasyonel okumaya çevirebilmek.
IDS/IPS/NDR’de imza–anomali dengesini, alarm kalitesi ve tuning döngüsüyle yönetebilmek.
SASE/SSE’nin politika tutarlılığı, görünürlük ve değişiklik/rollback açısından neyi değiştirdiğini değerlendirebilmek.
Platformlar arası denetim/okuma + kanıt paketleme komutlarını (Windows/Linux/macOS) güvenli biçimde kullanabilmek.
İki somut çıktı üretebilmek:
- Firewall Politika İncelemesi Runbook’u
- IDS/NDR Kalite & Tuning Runbook’u

3.1 Firewall türleri ve politika mantığı

Firewall, “paket geçsin mi/kalmasın mı?” kararının ötesinde bir politika yürütme katmanıdır. Etkili bir tasarımda hedef; yalnızca engellemek değil, kararın gerekçesini ve kanıtını üretebilmektir. Çekirdek ilke sabit kalır: default deny + least privilege + izlenebilir değişiklik.

Politika omurgası

“Açıkça izin verilmeyen engellenir” yaklaşımıyla başla; her allow kuralı için amaç, sahiplik ve süre tanımı olmadan kalıcı izin verme.

Operasyonel kalite

Doğru firewall, en çok kuralı olan değil; en az sürpriz üreten, değişiklikleri geri döndürülebilen ve denetimde açıklanabilen yapıdadır.

Firewall türleri — ne zaman, hangi bağlam?

Tür	Karar bağlamı	Güçlü yanı	Dikkat noktası
Stateless (ACL mantığı)	Tekil paket (5-tuple)	Hızlı, sade, öngörülebilir	Oturum/uygulama bağlamı sınırlı
Stateful firewall	Bağlantı durumu + paket	Yanıt trafiğini bağlamla yönetir	State tablosu doygunluğu ve timeout yönetimi kritik
NGFW	L3/L4 + uygulama/kimlik sinyali	Daha ince politika (kimlik, uygulama)	Kural karmaşıklığı ve yanlış sınıflandırma riski
Host-based firewall	Uç nokta süreç/uygulama bağlamı	Doğu-batı trafik için ek bariyer	Merkezi yönetim yoksa politika drift artar
FWaaS	Bulut üzerinden merkezi politika	Dağıtık kullanıcı/şubede tutarlılık	Bağımlılık, gecikme ve yol tasarımı doğru kurgulanmalı

Risk → sinyal → ilk savunma aksiyonu

Risk paterni	Tipik sinyal	İlk güvenli aksiyon
Aşırı izin (özellikle geniş egress)	Yeni hedef çeşitliliği + yüksek allow hit	Kuralı daralt, owner/expiry ekle, kontrollü yayınla
Aşırı kısıtlama	Tek serviste yoğun deny, ani iş kesintisi	Sıra/scope kontrolü yap, geçici istisnayı süreli aç
Görünmezlik (kanıt eksikliği)	Karar var ama log yok	Kritik allow + anlamlı deny için log politikasını düzelt
Policy drift	Davranış değişti, change kaydı yok	Konfig diff + kayıt korelasyonu, gerekirse rollback

60 saniyelik denetim checklist’i

Niyet net mi? Kural satırında “kim, nereden, nereye, ne, neden, süre” var mı?
Scope dar mı? Kaynak/hedef/servis gereğinden geniş mi (any-any kokusu)?
Sıra doğru mu? Üstteki geniş allow, alttaki dar deny’ı gölgeliyor mu?
Kanıt var mı? Hit count + allow/deny log + değişiklik kaydı birlikte okunabiliyor mu?
Geri dönüş hazır mı? Değişiklik başarısızsa uygulanacak rollback adımı yazılı mı?

3.2 Kural tasarımı

Kavramsal görsel: geniş kuralın dar kuralı gölgelemesi, analizde kanıt/kayıt eşlemesi, ardından kademeli daraltma ve rollback kriteriyle güvenli yayın döngüsü.

Kural tasarımı, yalnızca “trafik geçsin/geçmesin” yazmak değildir; her satırı okunabilir, açıklanabilir ve geri alınabilir hale getirme disiplinidir. Amaç, teknik doğruluk kadar operasyonel sürdürülebilirliktir: ekip değişse bile kuralın niyeti kaybolmamalıdır.

İyi kuralın özeti

Dar kapsam, net sahiplik, süreli istisna ve ölçülebilir etki. Bu dört unsur yoksa kural zamanla risk üretir.

En sık hata sınıfı

Geniş izin + yanlış sıra + kayıtsız istisna birleşimi; kısa vadede erişim sorununu çözer, orta vadede denetimi kırar.

Kural tasarımında temel ilkeler

İlke	Pratikte ne demek?	İhlal edilirse ne olur?
Default deny	Yalnızca açıkça tanımlı akışlara izin verilir.	Tanımsız akışlar görünmeden geçer, yüzey büyür.
Least privilege	Kaynak/hedef/servis/amaç en dar biçimde tanımlanır.	Geniş kurallar lateral hareket riskini artırır.
First match disiplini	Kural sırası düzenli ve gerekçeli tutulur.	Gölgeleme nedeniyle doğru kural hiç çalışmayabilir.
Ingress + egress birlikte	Giriş kadar çıkış yolu da yönetilir.	Dışa veri çıkışı ve kontrol kaybı artar.

Risk paternleri ve tespit sinyalleri

Risk paterni	Sahada görülen sinyal	Kanıt kaynağı
Gölgeleme (shadowing)	Alt kuralın hit count’ı sıfır, üstte geniş allow aktif	Kural sırası + hit count + log kesiti
Çakışma/örtüşme	Aynı akış birden fazla kurala uyuyor	Policy analyzer çıktısı + config diff
Objesiz yazım	IP/port satıra gömülü, anlam zor okunuyor	Konfig incelemesi + standart kontrol listesi
İstisna birikimi	Owner/expiry olmayan geçici kurallar kalıcılaşmış	Değişiklik kaydı + 30/90 gün diff raporu

Standartlaştırma şablonu

ALLOW_<APP>_<SRCZONE>_<DSTZONE>_<SERVICE>_<REASON>_<EXPIRY>

Alias/obje kullan: ham IP/port yerine okunur isimle yönet.
Her istisnada owner + gerekçe + bitiş tarihi zorunlu olsun.
Yaşam döngüsü: öneri → düşük riskli test → uygulama → gözlem → temizleme/iyileştirme.

Kısa denetim akışı (tik yerine nötr akış)

Adım	Soru	Hızlı karar
1. Niyet	Bu kural hangi iş ihtiyacını karşılıyor?	Belirsizse revizyon bekletilir.
2. Kapsam	Kaynak/hedef/servis gereğinden geniş mi?	Genişse daraltma taslağı çıkarılır.
3. Sıra	Üst kurallar bu satırı gölgeliyor mu?	Gölgeleme varsa sıra yeniden düzenlenir.
4. Kanıt	Hit count + log + change kaydı var mı?	Yoksa “kanıtsız kural” olarak işaretlenir.
5. Geri dönüş	Hata olursa rollback adımı hazır mı?	Hazır değilse değişiklik yayınlanmaz.

Bypass / erişim farkındalığı (savunma düzeyi)

Geniş egress izinleri ve gölgeleme, kontrol zincirini zayıflatabilir. Örnek (uydurma): FW allow: SRC=198.51.100.55 DST=203.0.113.50 SVC=TCP/443 kaydı varken aynı zaman aralığında proxy’de eşleşen kayıt yoksa, egress daraltma + proxy zorlaması + kural sırası denetimi birlikte ele alınmalıdır.

3.3 Proxy / Secure Web Gateway (SWG)

Proxy/SWG, web erişimini “internet açık mı kapalı mı?” seviyesinden çıkarıp kimlik + politika + kanıt düzeyine taşır. İyi bir tasarımda hedef, yalnız engelleme değil; kararın nedenini loglarla açıklayabilmektir.

Kontrol görevi

URL/kategori politikası, kimlik bağlamı ve merkezi kayıt ile web erişimini tutarlı yönetmek.

Kritik hassasiyet

TLS görünürlüğü teknik olduğu kadar yönetişim konusudur; minimizasyon ve yasal çerçeve olmadan yeni risk üretir.

Alan	Ne izlenir?	Hızlı yorum
Kimlik	Kullanıcı/cihaz bazlı allow-deny	IP bazlı politikaya göre daha güçlü izlenebilirlik sağlar
Kategori/URL	Yeni alan adı, ilk kez görülen kategori	İş dışı ama zararsız olabilir; karar için korelasyon gerekir
TLS	Doğrulama hataları, sertifika uyarıları	Tek başına hüküm değil; istemci ve proxy logu birlikte okunmalı
Tutarlılık	Proxy logu varken FW/flow karşılığı	Eşleşme yoksa proxy dışı egress şüphesi oluşur

Savunma yaklaşımı

Kimlik temelli erişim kullan; “kim yaptı?” sorusu cevapsız kalmasın.
Politika değişikliğini kayıt + rollback adımı olmadan yayınlama.
Triage üçlüsüyle karar ver: proxy kararı + DNS çözümleme + egress flow.

3.4 IDS/IPS / NDR

IDS/IPS/NDR için hedef “çok alarm” değil, aksiyon alınabilir alarm kalitesi üretmektir. Alarm bir sonuç değil; kanıtla doğrulanması gereken bir hipotezdir.

Yaklaşım	Odak	Operasyonel not
IDS	Tespit ve alarm üretimi	Triage kalitesi ve korelasyon kritik
IPS	Tespit + engelleme potansiyeli	Yanlış blok iş kesintisi riski taşır; rollback şart
NDR	Akış/davranış/anomali analizi	Bağlam yoksa false positive artabilir

Kalite riski

False positive SOC'u yorar; false negative sessiz başarısızlık üretir.

Sensör riski

Yanlış sensör yerleşimi ve zaman senkronu hatası, doğru tuning'i bile etkisiz bırakır.

Minimum kanıt seti

Alarm satırı: kimlik, kaynak/hedef, tetikleyici alan, zaman.
Korelasyon: firewall/proxy/flow ile aynı pencere eşleşmesi.
Gerekirse kısa PCAP kesiti ve zaman çizgisi.

Tuning döngüsü

Gözlemle: en sık ve en etkili alarm sınıflarını ayır.
Sınıflandır: beklenen iş trafiği mi, risk paterni mi?
İyileştir: eşik/bağlam/suppression düzenlemesini süreli uygula.
Doğrula: metrik karşılaştırmasıyla kör nokta üretmediğini göster.

3.5 SASE/SSE’ye giriş

SASE/SSE yaklaşımı, dağınık ağ ve güvenlik kontrollerini merkezi politika çatısında toplar. Bu bölümde odak ürün değil, politika tutarlılığı ve değişiklik güvenliğidir.

Katman	Kapsam	Kritik operasyon noktası
SASE	Ağ + güvenlik yeteneklerinin birleşik yaklaşımı	Geniş etki alanı nedeniyle kontrollü yayın gerekir
SSE	ZTNA, SWG, CASB, FWaaS gibi güvenlik servisleri	Kimlik/cihaz bağlamı sağlıklı değilse erişim tutarsızlığı artar

Uygulama disiplini

Golden policy tanımla; istisnaları süreli ve sahipli yönet.
Değişiklikleri küçük kapsamla yayınla; geri dönüş koşulunu baştan yaz.
Karar kayıtlarını (allow/deny) değişiklik zaman çizgisiyle birlikte sakla.

3.6 pfSense (opsiyonel ekosistem okuryazarlığı)

pfSense burada ürün kurulumu için değil, firewall ekosistemindeki ortak okuma disiplinini pekiştirmek için kullanılır: kural, NAT, state, alias ve log birlikte değerlendirilir.

İncelenen alan	Neden önemli?	Risk sinyali
Kural sırası/scope	Gölgeleme ve aşırı izin riskini belirler	Geniş allow yüksek hit alıyor
NAT etkisi	Gerçek kaynak/hedef yorumunu değiştirir	Logla akış yorumu çelişiyor
State tablosu	Yoğunluk ve hedef dağılımını gösterir	Beklenmeyen uzun/çok oturum
Alias yönetimi	Kural okunabilirliğini ve güvenliğini artırır	Alias kapsamı sessizce genişlemiş

Alias'ları iş amacıyla adlandır.
İstisnaları owner + expiry ile tut.
Değişiklik sonrası hit count + log örüntüsü doğrulaması yap.

3.7 Denetim/okuma komutları (güvenli doğrulama + kanıt)

Amaç saldırı değil; “kontrol gerçekten çalışıyor mu?” sorusuna denetlenebilir cevap üretmek. Tüm komutlar izinli/yerel okuma ve kanıt üretimi içindir.

Ortak kanıt disiplini

Zaman damgası al (UTC tercih et).
Çıktıyı kanıt klasörüne dosyala.
Hash/manifest ile bütünlük ekle.
Her çıktı için “hangi hipotezi test ediyor?” notu yaz.
Raporu Bulgu → Etki → Öneri → Kanıt formatına bağla.

3.8 HOW-TO: Firewall Politika İncelemesi Runbook’u

Amaç: kesinti üretmeden kural kalitesini denetlemek, riskli satırları kanıtla işaretlemek ve güvenli düzeltme/rollback planı üretmek.

Faz	Ana soru	Çıktı
Hazırlık	Neyi, hangi pencerede inceliyoruz?	Kapsam + veri kaynakları + kanıt klasörü
İnceleme	Hangi kurallar riskli?	Riskli kural listesi + gerekçe
Doğrulama	Bulguyu ne doğrular/ne çürütür?	Hit/log/flow korelasyonu
Düzeltme	Daraltma nasıl ve hangi sırayla?	Kademeli uygulama planı
Rollback	Ne olursa geri döneriz?	Eşikler + geri dönüş adımları

Uygulama özeti

Any-any, geniş egress, yönetim servislerinde geniş izin ve sahipsiz istisnaları çıkar.
Her kural için 5'li niyeti doğrula: kim, nereden, nereye, ne, neden/süre.
Gölgeleme ve NAT/route etkisini log + flow ile çapraz kontrol et.
Düzeltmede önce daralt, sonra izle; iş etkisi artarsa rollback uygula.

3.9 HOW-TO: IDS/NDR Kalite & Tuning Runbook’u

Amaç: gürültüyü azaltırken tespit kabiliyetini korumak. Tuning, ölçmeden yapılan ayar değil; metrikle doğrulanan bir kalite döngüsüdür.

Ölçülecek çekirdek metrikler

Günlük alarm hacmi
Aksiyon alınan alarm oranı
Kanıtlanmış false positive sayısı
Ortalama triage süresi
Sensör sessizlik/süreklilik kontrolü

Adım	Ne yapılır?	Başarı ölçütü
Örnekleme	7 gün hacim, 30 gün etki bazlı alarm tiplerini çıkar	En kritik alarm sınıfları netleşir
Karar kartı	Her tip için karşı kanıt, ek veri, eşik ve eskalasyon tanımla	Triage kararı tutarlı hale gelir
Tuning	Bağlam/threshold/süreli suppression uygula	Gürültü azalır, kritik alarm kaçırtılmaz
Doğrulama	Önce/sonra metriklerini karşılaştır	False positive düşer, kör nokta oluşmaz

Rollback tetikleyicileri

Doğrulayıcı loglar varken alarm sessizliği oluşması.
Sensör kesintisi veya beklenmedik veri kaybı.
IPS modunda iş kesintisi işaretlerinin artması.

3.10 Komut & Araç Okuryazarlığı

Bu bölüm komut ezberi değil, kanıt üretim akışıdır. Hedef: her komut çıktısını bir hipotezle ilişkilendirip raporda izlenebilir hale getirmek.

Kanıt paketi

time_utc.txt (zaman referansı)
notes.txt (hangi hipotez?)
platforma göre denetim çıktıları
manifest.sha256 (bütünlük)

Güvenli kullanım

Yalnızca izinli kapsamda okuma/kanıt komutları kullanılır; geniş tarama, yetkisiz hedef ve saldırı adımı yoktur.

Platform bazlı hızlı komut seti

Platform	Amaç	Örnek komut
Windows (PowerShell)	Zaman + FW durumu + proxy + hash	`Get-Date -AsUTC -Format o > .\evidence\time_utc.txt` `Get-NetFirewallProfile \| Select Name,Enabled,DefaultInboundAction,DefaultOutboundAction > .\evidence\fw_profiles.txt` `netsh winhttp show proxy > .\evidence\winhttp_proxy.txt` `Get-FileHash .\evidence\fw_profiles.txt -Algorithm SHA256`
Linux	Zaman + firewall envanteri + proxy env + manifest	`date -u +"%Y-%m-%dT%H:%M:%SZ" \| tee evidence/time_utc.txt` `sudo nft list ruleset \| tee evidence/nft_ruleset.txt` `env \| grep -i proxy \| tee evidence/proxy_env.txt` `sha256sum evidence/* \| tee evidence/manifest.sha256`
macOS	Zaman + proxy + PF görünürlüğü + manifest	`date -u +"%Y-%m-%dT%H:%M:%SZ" \| tee evidence/time_utc.txt` `scutil --proxy \| tee evidence/macos_proxy.txt` `sudo pfctl -sr \| tee evidence/pf_rules.txt` `shasum -a 256 evidence/* \| tee evidence/manifest.sha256`

Örnek terminal oturumları (kavramsal)

Aşağıdaki kutular, Modül 3'teki denetim adımlarının sahadaki çıktı görünümünü simüle eder. Komutlar okuma/kanıt üretimi içindir.

Windows PowerShell

PowerShell 7 — Denetim (örnek)

PS C:\evidence> Get-Date -AsUTC -Format o 2026-04-17T10:21:48.1123456Z PS C:\evidence> Get-NetFirewallProfile | Select Name, DefaultInboundAction, DefaultOutboundAction Domain Block Allow Private Block Allow Public Block Allow PS C:\evidence> netsh winhttp show proxy Direct access (no proxy server).

Linux Shell

bash — Kanıt toplama (örnek)

analist@soc:~/evidence$ date -u +"%Y-%m-%dT%H:%M:%SZ" 2026-04-17T10:22:03Z analist@soc:~/evidence$ sudo nft list ruleset | head -n 10 table inet filter { chain input { type filter hook input priority 0; policy drop; } chain output { type filter hook output priority 0; policy accept; } } analist@soc:~/evidence$ sha256sum nft_ruleset.txt 4a75...e19b nft_ruleset.txt

macOS Terminal

Terminal — zsh (örnek)

analist@MacBook evidence % scutil --proxy | head -n 12 <dictionary> { HTTPEnable : 1 HTTPProxy : proxy.corp.local HTTPPort : 8080 } analist@MacBook evidence % sudo pfctl -sr | head -n 6 block drop in all pass out all keep state

Tek hedef doğrulama (izinli)

Windows: Test-NetConnection -ComputerName 192.0.2.10 -Port 443
Linux/macOS: nc -zv 192.0.2.10 443
Sonucu tek başına hüküm sayma; firewall/proxy loglarıyla birlikte yorumla.

Wireshark / tcpdump / tshark ile kanıt üretimi

Adım	Ne yaparsın?	Neden?
Hipotez	Önce soruyu yaz: “443 engelleniyor mu?”	Yakalamayı gereksiz büyütmeyi önler
Kısa yakalama	`sudo tcpdump -i <iface> host 192.0.2.10 and tcp port 443 -w evidence/test_443.pcap`	Tek hedef/tek servis kanıtı üretir
Okuma	Conversations, Protocol Hierarchy, Expert Info	Davranış özetini hızlı çıkarır
Korelasyon	PCAP sonucu + FW/proxy logu	“drop mı, servis kapalı mı?” ayrımını netleştirir
Bütünlük	`sha256sum evidence/test_443.pcap >> evidence/manifest.sha256`	Rapor kanıtını denetlenebilir yapar

tshark kısa okuma örneği

tshark — PCAP üzerinden hızlı korelasyon

analist@soc:~/evidence$ tshark -r test_443.pcap -q -z conv,tcp TCP Conversations 192.0.2.20:51422 <-> 192.0.2.10:443 22 frames analist@soc:~/evidence$ tshark -r test_443.pcap -Y "tcp.flags.reset==1" -T fields -e frame.time -e ip.src -e ip.dst Apr 17, 2026 10:23:11.211 192.0.2.10 192.0.2.20 # Yorum: RST hedeften dönüyorsa servis/policy birlikte doğrulanır.

Rapor cümlesi örneği: “Bu kanıt seti, 192.0.2.10:443 erişiminin politika kaynaklı engel mi yoksa servis kaynaklı hata mı olduğunu doğrulamak için üretilmiştir.”

3.11 Operasyonel Senaryo — “Gölgelenen kural mı, proxy tutarsızlığı mı, NDR neden bağırıyor?”

Senaryo yalnızca izinli/lab bağlamında veya uydurma verilerle yürütülür. Amaç suç atfetmek değil, kanıt zinciriyle doğru katmanı bulmaktır.

Belirti

Web erişimi dalgalı, NDR dış hedef anomalisi üretiyor, DB erişimi için beklenmeyen izin iddiası var.

Ana risk

Proxy tutarsızlığı + gölgelenen kural birlikteyse görünürlük ve segmentasyon aynı anda zayıflar.

Hipotez tablosu

#	Hipotez	İlk kanıt kaynağı
1	Proxy/SWG politika değişimi erişimi bozdu	Proxy karar logları + değişiklik kaydı
2	Egress genişledi, proxy dışı çıkış oluştu	FW allow + proxy eşleşme kontrolü + flow
3	DB erişimi gölgelenen kuraldan açıldı	Kural sırası + hit count + tek hedef doğrulama
4	NDR false positive üretiyor	NDR alarmı + DNS/proxy/FW karşı kanıtı
5	Zaman/kayıt tutarsızlığı var	UTC hizalama + log sürekliliği

Analiz akışı

UTC hizalaması yap ve tek zaman penceresi tanımla.
Proxy kullanımını istemci çıktısı + proxy loguyla doğrula.
FW outbound kaydını proxy/flow ile çaprazla.
DB erişim iddiasında gölgeleme ve hit count kanıtını sabitle.
NDR alarmını “yeni hedef” bağlamında diğer telemetriyle eşleştir.

Karar ve rapor

Proxy dışı çıkış varsa: egress daralt + proxy zorlamasını güçlendir + istisnaları süreli/sahipli yap.
DB erişimi gölgeleme kaynaklıysa: geniş kuralı kademeli daralt, etkiyi izle, rollback hazır tut.
NDR gürültüsünde suppression yerine bağlam/eşik iyileştirmesi uygula ve metrikle doğrula.
Raporu her zaman Bulgu → Etki → Öneri → Kanıt formatında teslim et.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Firewall Trafiği politika ile izinli/izinsiz ayıran kontrol katmanı; modern yapılarda state/uygulama/kimlik bağlamı kullanabilir.

ACL Erişim Kontrol Listesi; genellikle paket/başlık alanlarına dayalı stateless filtreleme mantığı.

Stateless filtreleme Her paketi tekil değerlendirir; oturum bağlamı sınırlıdır.

Stateful inspection Bağlantı/oturum durumunu takip ederek karar veren yaklaşım.

NGFW Uygulama/kimlik bağlamı ekleyen yeni nesil firewall yaklaşımı.

Default deny Açıkça izin verilmemiş trafiği engelleme ilkesi.

Least privilege En az yetki; yalnızca gereken kaynak/hedef/servise izin verme prensibi.

Shadowing (Gölgeleme) Üstteki geniş kuralın, alttaki dar kuralı işlevsiz bırakması.

Policy drift Zamanla politika niyetten ve kayıttan sapar; istisnalar kalıcılaşır.

Proxy / SWG Web erişimini kimlik/kategori/politika ile yöneten güvenli web geçidi.

TLS görünürlüğü Kurum içi politikalarla, gerekli olduğunda şifreli trafikte denetim yapılabilmesi; yönetişim ve gizlilik kritik.

IDS İzinsiz giriş tespit sistemi; trafik/olay sinyali üretir.

IPS Önleme sistemi; bazı konumlandırmalarda trafiği engelleyebilir (inline).

İmza tabanlı tespit Bilinen örüntülere göre tespit yaklaşımı.

Anomali tabanlı tespit Normal davranıştan sapmaya göre tespit yaklaşımı.

NDR Ağ davranışı/akış verisi üzerinden anomali ve korelasyonla tespit yaklaşımı.

SASE Ağ + güvenliği bulut tabanlı birleşik mimaride sunan yaklaşım.

SSE SASE’nin güvenlik servisleri bileşeni (ZTNA/SWG/CASB/FWaaS vb.).

ZTNA Zero Trust Network Access; kimlik ve duruşa göre uygulamalara erişim.

CASB Cloud Access Security Broker; SaaS erişiminde politika ve görünürlük katmanı.

FWaaS Firewall as a Service; firewall yeteneğinin servis olarak sunulması.

Hit count Bir kuralın kaç kez eşleştiğini gösteren sayaç/analitik metriği.

Rollback Değişiklikten geri dönüş planı ve uygulanabilir geri alma adımı.

Kanıt manifesti Kanıt dosyalarının hash listesini içeren bütünlük çıktısı (manifest.sha256).

Kendini Değerlendir

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

Aşağıdaki bulgulardan hangisi “gölgeleme (shadowing)” ihtimalini en güçlü şekilde destekler?

A) Kural setinde çok sayıda deny kuralı bulunması

B) “Allow ANY → ANY” benzeri geniş bir kuralın, daha dar bir “Deny DB” kuralının üstünde yer alması ve hit count’ının yüksek olması

C) Proxy loglarında TLS hata sayısının artması

D) NDR’de alarm sayısının düşmesi

E) SASE portalında oturum açma hatası görülmesi

Doğru: B
Gerekçe: Geniş üst kural + yüksek hit count, alttaki dar kuralın fiilen çalışmadığını güçlü biçimde gösterir. Diğerleri gölgelemenin doğrudan kanıtı değildir.

“Proxy’den mi çıkıyor, yoksa proxy dışı egress mi var?” sorusunda en iyi kanıt yaklaşımı hangisidir?

A) Kullanıcı beyanını tek başına esas almak

B) Sadece proxy loglarına bakmak

C) Proxy logu + firewall allow logu + aynı zaman penceresinde flow özetiyle korelasyon kurmak

D) Sadece NDR alarm açıklamasını okumak

E) Sadece DNS logunu incelemek

Doğru: C
Gerekçe: Tutarlılık testi, en az iki kontrol noktasının kayıtlarını aynı zaman penceresinde eşleştirmeyi gerektirir. Tek kaynak kanıt zayıftır.

Tek hedefe bağlantı testinde Wireshark’ta SYN paketleri gidiyor ancak yanıt gelmiyorsa ve firewall logunda da deny görünmüyorsa en doğru sonraki adım hangisidir?

A) Hemen “kesin saldırı var” diye raporlamak

B) Sensör/ayna portu/yanlış arayüz yakalama ihtimalini kontrol edip kanıtı yeniden üretmek

C) Tüm port aralığını taramak

D) Proxy’yi devre dışı bırakmak

E) IDS’i kapatmak

Doğru: B
Gerekçe: “Deny yok + yanıt yok” durumu ölçüm hatası/sensör körlüğü olabilir. Yetkisiz tarama ve kontrol kapatma hem riskli hem kapsam dışıdır.

IDS/NDR’de yüksek false positive görülüyor. En sağlıklı ilk tuning hamlesi hangisidir?

A) Alarm sayısını sıfıra indirmek için geniş suppression uygulamak

B) Baseline çıkarıp alarm sınıflandırması yaparak kritik varlık/izinli servis gibi bağlam eklemek

C) Log toplamayı azaltmak

D) IPS’i inline modda agresif bloklamaya almak

E) Değişiklik kaydı tutmadan eşikleri rastgele yükseltmek

Doğru: B
Gerekçe: Gürültüyü azaltmanın en güvenli yolu “bağlam eklemek” ve metrikle doğrulamaktır. Diğer seçenekler kör nokta/iş kesintisi riski taşır.

Aşağıdakilerden hangisi IDS ile IPS arasındaki farkı operasyonel açıdan en doğru anlatır?

A) IDS her zaman trafiği engeller, IPS sadece izler

B) IDS izler ve uyarı üretir; IPS bazı konumlandırmalarda engelleme yapabildiği için değişiklik/rollback disiplini daha kritiktir

C) IDS sadece endpoint’te çalışır, IPS sadece bulutta çalışır

D) IDS anomali tespiti yapamaz, IPS sadece imza tespiti yapar

E) IDS log üretmez, IPS log üretir

Doğru: B
Gerekçe: Temel ayrım “tespit” vs “önleme potansiyeli”dir; önleme iş kesintisi riski nedeniyle daha sıkı operasyon ister.

SSE ile SASE ilişkisini en doğru ifade eden seçenek hangisidir?

A) SSE, SASE’nin ağ (SD-WAN) bileşenidir

B) SASE, SSE’nin sadece proxy kısmıdır

C) SSE, SASE’nin güvenlik servisleri bileşenidir (ZTNA/SWG/CASB/FWaaS gibi)

D) SSE sadece on-prem cihazları kapsar

E) SASE sadece veri merkezinde çalışır

Doğru: C
Gerekçe: SSE güvenlik servislerine odaklanır; SASE daha geniş bir birleşimi hedefler.

“Policy drift” için en güçlü gösterge kombinasyonu hangisidir?

A) Kural isimleri çok uzun

B) Bir kuralın owner/expiry/gerekçesi yok ve değişiklik kaydı bulunmadan scope’u genişlemiş görünüyor

C) Proxy logları çok kalabalık

D) IDS alarmları hiç yok

E) Wireshark filtreleri çalışmıyor

Doğru: B
Gerekçe: Sahipsiz-süresiz istisna + kayıt dışı değişim, drift’in özüdür.

Kanıt paketinde “manifest.sha256” neden bulunur?

A) Alarm üretmek için

B) Logları şifrelemek için

C) Kanıt dosyalarının bütünlüğünü (sonradan değişmediğini) göstermek için

D) Firewall kuralı eklemek için

E) Proxy’yi kapatmak için

Doğru: C
Gerekçe: Hash manifest, kanıtın denetlenebilirliğini artırır.

Loglama stratejisinde en doğru yaklaşım hangisidir?

A) Her allow/deny satırını sınırsız loglamak

B) Loglamayı tamamen kapatmak

C) Kritik allow’lar ve anlamlı deny’lar üzerinden, triage’ı boğmadan ölçülebilir bir logging tasarlamak

D) Sadece kullanıcı şikâyetine göre log açmak

E) Sadece NDR alarmı gelince log toplamak

Doğru: C
Gerekçe: Amaç “kanıt üretmek”tir; gürültü yönetimi de güvenliğin parçasıdır.

“Tek hedef/tek servis” bağlantı doğrulamasının (Test-NetConnection / nc -zv) doğru kullanımı hangisidir?

A) Kurum dışı rastgele hedeflerde geniş denemeler yapmak

B) İzinli ortamda bilinen hedef/servisi doğrulayıp sonucu firewall/proxy logları ve gerekiyorsa kısa PCAP ile kanıta bağlamak

C) Port aralığı taraması yapmak

D) Sadece “başarısız” sonucunu raporlamak, log bakmamak

E) Proxy’yi devre dışı bırakıp tekrar denemek

Doğru: B
Gerekçe: Bu araçlar tek başına hüküm vermez; doğru yöntem korelasyon + kanıt zinciridir. Tarama ve kontrol devre dışı bırakma kapsam dışıdır.

Kapanış — Bu modülde neler kazandın?

Firewall/ACL/proxy/IDS/NDR kontrollerini zincir olarak yönetme bakışı
Kural tasarımında okunabilirlik, sahiplik, süre, gerekçe disiplininin güvenliğin parçası olduğunu
Proxy/SWG ile egress kontrolü tutarsızlaştığında görünürlük ve karar kalitesinin düştüğünü
IDS/NDR’de hedefin “alarmı azaltmak” değil, aksiyon alınabilir kalite üretmek olduğunu
SASE/SSE’de merkezi politikanın gücünün, değişiklik/rollback disiplinine bağımlı olduğunu
Denetim/okuma komutları + hash manifest ile kanıt standardında raporlama refleksini
İki runbook ile değişiklik–doğrulama–kanıt–rollback döngüsünü işletmeyi

MODÜL 4 — Güvenlik Kontrolleri II: Segmentasyon, VLAN, DMZ, Zero Trust

Kavramsal şema: dış → DMZ (çift sınır) → iç segmentler (VLAN); trunk’ta 802.1Q ile bir hat üzerinde çok etiket; Zero Trust ise “içeride güven” yerine kimlik–cihaz–politika–denetim döngüsü.

Düşün: firewall kuralları savunmanın “ilk hattı”ysa, segmentasyon savunmanın mimari temelidir. Düz (flat) bir ağ, saldırgan için “otoban” gibidir; bir uç ele geçirildiğinde yanlara doğru ilerlemek (lateral movement) kolaylaşır. Segmentasyon ise bu otobana “hız kesiciler” koyar: hangi bölgenin hangi bölgeyle hangi servisler üzerinden konuşabileceğini tasarım + politika + kanıt ile yönetir. Bu modülde VLAN ile güvenli bölgeleme, trunking’in kavramsal riskleri, DMZ tasarım ilkeleri ve Zero Trust yaklaşımına giriş birlikte ele alınır. Hedef “şema çizdim oldu” değil; Akış Matrisi ile doğrulanan, log/flow/PCAP ile kanıtlanabilen ve değişiklik–geri dönüş (rollback) disiplini olan bir kontrol mimarisi kurmaktır. Bu modül “bypass nasıl yapılır?” anlatmaz; bunun yerine segmentasyon boşluğu doğurabilecek hataların iz/sinyal düzeyinde nasıl fark edileceğini ve nasıl düzeltileceğini öğretir.

Bu Dersin Hedefleri

Segmentasyonun güvenlik değerini (blast radius, lateral movement, veri erişimi) operasyonel sonuçlarıyla açıklamak.
VLAN’ları “mantıksal güvenlik bölgesi” gibi konumlandırmak; L2/L3 sınırlarının güvenlik etkisini ayırt etmek.
Trunking’in kavramsal risklerini (aşırı izinli VLAN taşıma, native VLAN, kontrolsüz otomasyon/varsayılanlar, policy drift) kanıt temelli değerlendirmek.
DMZ’yi internet–DMZ–iç ağ sınırlarında minimal ve denetlenebilir akışlarla tasarlamak.
Zero Trust’in “iç ağ = güven” varsayımını nasıl kırdığını kavramsal olarak anlamak (ürün seçmeden).
Akış Matrisi ile segmentasyon doğrulaması için runbook üretmek: hazırlık → uygulama → doğrulama → kanıt paketleme → geri dönüş.

4.1 Segmentasyonun güvenlik değeri

Segmentasyonun amacı trafiği tamamen durdurmak değil; trafiği tanımlı, gerekçeli ve kanıtlanabilir hale getirmektir. Böylece bir olay olduğunda etki alanı küçülür, karar süresi kısalır.

Kazanç

Blast radius küçülür, lateral movement zorlaşır, olay triage süresi azalır.

Tipik hata

“VLAN var, izolasyon tamam” varsayımı; L3 politika ve log kanıtı olmadan güven hissi üretir.

Sinyal	Ne anlatır?	İlk aksiyon
Beklenmeyen east-west akış	Bölge sınırı gevşemiş olabilir	Akış Matrisi satırı var mı kontrol et
Allow hedef/port çeşitliliği artışı	Kural kapsamı genişlemiş olabilir	Kural diff + owner/expiry denetimi
Kayıt dışı trafik değişimi	Policy drift ihtimali	Change kaydı karşılaştırması

Akış Matrisi olmadan kural açma.
Default deny + explicit allow çizgisini koru.
Daraltma değişikliklerini kademeli yap, rollback eşiğini baştan yaz.

4.2 VLAN ve güvenli bölgeleme

VLAN, güvenli bölgelemenin L2 temelidir; güvenlik sınırı ise inter-VLAN geçişte uygulanan L3/L4 politikayla tamamlanır.

Katman	Rol	Eksikse risk
VLAN (L2)	Mantıksal yayın alanı ayrımı	Farklı risk sınıfları aynı düzlemde kalır
Inter-VLAN Policy (L3/L4)	Bölgeler arası akışı kısıtlama	Yanlara geçiş kolaylaşır
Kimlik/bağlam	Yetkiyi cihaz/kullanıcıya bağlama	“Ağa girdi = her şeye erişim” algısı doğar

VLAN tasarımını iş kritikliğine göre yap (user/server/mgmt/guest/iot).
Her inter-VLAN allow satırını matrise bağla.
Yönetim ağını ayrı policy ile koru; geniş yönetim portlarından kaçın.

Savunma farkındalığı: Akış Matrisi’nde olmayan USER → SERVER akışı görünüyorsa “yanlış kullanım” değil, önce politika ve kayıt tutarlılığı kanıtlanmalıdır.

4.3 Trunking güvenliği (kavramsal riskler)

Trunking esneklik sağlar; ama fazla geniş taşınan VLAN listesi segmentasyonun görünmeden aşınmasına yol açabilir.

Risk	Sinyal	Kontrol
Geniş allowed VLAN list	Tasarımda olmayan VLAN'lar trunkta aktif	En az VLAN taşıma, port profili standardı
Native VLAN tutarsızlığı	Beklenmeyen L2 davranış/uyumsuzluk	Native VLAN amacı ve kapsamını netleştir
Drift	Kayıtsız trunk profil değişimi	Önce/sonra konfig kanıtı + rollback

Trunk değişikliğini küçük kapsamda yayınla.
Önce/sonra konfig farkını kaydet.
Uygulama sonrası log/flow/PCAP ile tasarım uyumunu doğrula.

4.4 DMZ tasarım ilkeleri

DMZ’nin değeri “dışarı bakan sunucuyu ayırmak” kadar, DMZ ↔ iç ağ geçişini minimum ve denetlenebilir tutmaktır.

Kritik ilke

DMZ → iç ağ akışları varsayılan kapalı, yalnız gerekçeli ve dar izinli olmalı.

Sık sorun

Geniş allow + gölgelenen deny birleşimi, politika niyeti ile gerçek davranışı ayırır.

Kontrol	Ne doğrulanır?	Kanıt
DMZ→iç ağ kısıtı	Yalnız back-end zorunlu akış var mı?	FW kural ID + log kesiti
DMZ egress	Dış hedefler gerekçeli mi?	Flow özeti + allowlist eşleşmesi
Gölgeleme	Üst kural alttaki deny'ı eziyor mu?	Kural sırası diff + hit count

4.5 Zero Trust’e giriş

Zero Trust, “içeridesin, güvenlisin” varsayımını kaldırır; her erişimi kimlik, cihaz duruşu, bağlam ve politika ile tekrar değerlendirir.

Yanlış yaklaşım	Doğru yaklaşım
“Her şeyi kapat”	Kademeli, kanıt temelli sıkılaştırma
Kalıcı istisna	Owner + expiry + gerekçe
Tek seferlik dönüşüm	Kritik varlıklardan başlayarak aşamalı geçiş

Golden policy tanımla, istisnaları yaşam döngüsüyle yönet.
Erişim karar loglarında “kim/neye/neden” görünürlüğünü zorunlu tut.
Her değişiklik için rollback metriğini baştan belirle.

4.6 Komut & Araç Okuryazarlığı (Windows / Linux / macOS + Wireshark)

Bu bölüm komut ezberi değil; segmentasyon hipotezini kanıtla doğrulama akışıdır. Tüm komutlar izinli/yerel kapsamda okuma ve kanıt üretimi içindir.

Kanıt rutini

Zaman damgası al (UTC önerilir).
Çıktıları `evidence/` altında dosyala.
Her çıktı için hipotez notu yaz.
Hash/manifest ile bütünlük ekle.

Güvenli sınır

Tek hedef/tek servis doğrulama yapılır; tarama ve kapsam dışı deneme yapılmaz.

Platform	Önerilen çekirdek komutlar	Amaç
Windows	`Get-NetIPConfiguration`, `Get-NetRoute`, `Test-NetConnection host -Port 443`	Segment + route görünürlüğü ve tekil servis doğrulaması
Linux	`ip -d link show`, `ip route show`, `nc -zv host 443`, `tcpdump -e ... vlan ...`	VLAN/route kanıtı ve hedefli trafik kesiti
macOS	`networksetup -listVLANs`, `netstat -rn`, `nc -zv host 443`	VLAN tanımı, yönlendirme ve erişim doğrulaması

Örnek terminal oturumları (kavramsal)

Aşağıdaki kutular segmentasyon denetiminde tipik çıktı görünümünü simüle eder; komutlar okuma/kanıt üretimi içindir.

Windows PowerShell

PowerShell — ağ ve tekil test

PS C:\evidence> Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Select NextHop, InterfaceAlias NextHop InterfaceAlias 192.0.2.1 Ethernet PS C:\evidence> Test-NetConnection -ComputerName 203.0.113.10 -Port 443 | Select TcpTestSucceeded TcpTestSucceeded : True # Sonucu FW log ile eşle; tek başına hüküm değildir.

Linux

bash — route + bağlantı

analist@host:~/evidence$ ip route show default default via 192.0.2.1 dev eth0 analist@host:~/evidence$ nc -zv 203.0.113.10 443 Connection to 203.0.113.10 443 port [tcp/https] succeeded!

macOS

Terminal — zsh

analist@MacBook evidence % networksetup -listVLANs VLAN UserNet on en0 analist@MacBook evidence % netstat -rn | head -n 8 Destination Gateway Flags default 192.0.2.1 UGSc

tshark — segmentasyon hipotezi (örnek)

tshark — VLAN + hedef akış

analist@host:~/evidence$ tshark -r vlan_sample.pcap -Y "vlan.id == 10 && ip.addr == 203.0.113.10" -T fields -e frame.time -e vlan.id -e ip.src -e ip.dst | head -n 4 Apr 17, 2026 14:01:02.112 10 198.51.100.20 203.0.113.10 # Matris satırıyla aynı kaynak/hedef/servis mi kontrol et.

Wireshark okuryazarlığı (segmentasyon)

Filtre: vlan veya eth.type == 0x8100.
Belirli VLAN: vlan.id == 10.
Hedef akış: ip.addr == 203.0.113.10 && tcp.port == 443.
Conversations/Endpoints çıktısını dışa aktar ve manifest'e ekle.

4.7 HOW-TO: Segmentasyon Doğrulama (Akış Matrisi ile)

Bu runbook segmentasyonun dokümanda değil sahada çalıştığını kanıtlamayı hedefler.

Faz	Ana çıktı	Kritik soru
Hazırlık	Kapsam + Akış Matrisi şablonu	Neyi doğruluyoruz?
Eşleştirme	Matriz vs gerçek politika farkı	Hangi allow kayıt dışı?
Doğrulama	Tekil test sonuçları	İzinli akış geçiyor, izinsiz akış düşüyor mu?
Kanıt paketleme	Log/flow/pcap + manifest	Denetlenebilir mi?
Rollback	Geri dönüş kriteri	Hangi eşiği aşarsa geri alınır?

Matriste olmayan allow kuralını drift adayı olarak işaretle.
Matriste olup sahada çalışmayan akışı iş kesintisi adayı olarak ayır.
Testlerde tarama yapma; 1-2 kritik izinli ve 1-2 izinsiz akış yeterlidir.
Sonucu her zaman Bulgu → Etki → Öneri → Kanıt formatına bağla.

Kanıt klasörü örneği (terminal)

bash — mod4_segmentation kanıt paketi

analist@host:~/YYYYMMDD_mod4_segmentation/evidence$ ls -la flow_dmz_summary.txt fw_rules_export.diff vlan_sample.pcap manifest.sha256 analist@host:~/.../evidence$ sha256sum * | tee -a manifest.sha256 a1b2...c3d4 flow_dmz_summary.txt # Rapor Kanıt bölümüne manifest referansı eklenir.

4.8 Operasyonel Senaryo — “DMZ’den iç ağa beklenmedik ‘ALLOW’ görünüyor: kural gölgeleme mi, drift mi?”

Belirti: DMZ→iç ağ trafiğinde beklenen DROP yerine aralıklı ALLOW kayıtları görülüyor. Hedef, “ihlal” etiketi atlamak değil; bunun gölgeleme mi drift mi olduğunu kanıtla ayırmak.

Hipotez	Doğrulayıcı kanıt	Karşı kanıt
Gölgeleme	Üst geniş allow + alt dar deny + hit count farkı	Kural sırası doğru ve deny hit alıyorsa
Drift	Matriste olmayan allow + change kaydı yok	Onaylı süreli istisna kaydı varsa
Yanlış etiketleme	Kaynak arayüz/bölge uyuşmazlığı	Flow/pcap kaynak doğrulaması DMZ'yi net doğruluyorsa

Analiz akışı

ALLOW logunu ilgili kural ID'siyle matrise eşleştir.
Kural sırası ve hit count ile gölgeleme testini yap.
Flow/pcap ile kaynağın gerçekten DMZ olduğunu doğrula.
Change kaydı yoksa drift olasılığını yükselt.

Karar ve rapor

Matriste yoksa: aşırı izin/drift adayı; daraltma + owner/expiry zorunlu.
Matriste var ama kararsızsa: sıra/öncelik düzeltmesi ve yeniden doğrulama.
Belirsizlikte kesin hüküm verme; kanıt setini güçlendir.
Raporu Bulgu → Etki → Öneri → Kanıt zinciriyle tamamla.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Segmentasyon Ağı güvenlik bölgelerine ayırıp bölgeler arası akışı allowlist ile yönetme yaklaşımı

Blast radius Bir ihlal/arıza olduğunda etkinin yayılabileceği alanın büyüklüğü

East–West trafik Kurum içi sistemler arası (yan yana) trafik

VLAN Aynı fiziksel altyapıda mantıksal L2 yayın alanı oluşturan bölgeleme yöntemi

Inter-VLAN policy VLAN’lar arası L3 geçişte uygulanan ACL/firewall politikası

Trunking Bir link üzerinden birden çok VLAN’ın taşınması

Allowed VLAN list Trunk üzerinden taşınmasına izin verilen VLAN listesi

Native VLAN Etiketlenmemiş trafiğin varsayılan eşleştiği VLAN (kavramsal risk kaynağı olabilir)

DMZ İnternet erişimli servislerin iç ağdan ayrıldığı ara bölge

Zero Trust “İç ağ güvenlidir” varsayımını reddedip erişimi kimlik/bağlam/policy ile doğrulama yaklaşımı

Akış Matrisi Kaynak–hedef–servis–amaç–sahip–süre bilgisiyle izinli trafiği tanımlayan doğrulama tablosu

Policy drift Politikaların zamanla niyetten/kayıttan sapması; istisnaların kontrolsüz birikmesi

Kendini Değerlendir

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

Aşağıdakilerden hangisi “VLAN var → izolasyon var” yanılgısının en doğru düzeltmesidir?

A) VLAN izolasyonu her zaman L3’ten bağımsızdır.

B) VLAN yalnızca broadcast’i azaltır; güvenlik etkisi yoktur.

C) VLAN, L2’de bölge yaratır; fakat VLAN’lar arası geçiş (routing) varsa güvenlik sınırı için L3 politika gerekir.

D) VLAN izolasyonu için yalnız trunking yeterlidir.

E) VLAN izolasyonu yalnız DMZ’de kullanılır.

Doğru: C
Gerekçe: VLAN L2 sınırı sağlar; fakat inter-VLAN routing varsa trafik L3’te politika ile kontrol edilmedikçe “izolasyon” varsayımı hatalı olur. A/D/E yanlış genelleme, B ise VLAN’ın pratikteki mimari değerini yok sayar.

Akış Matrisi yaklaşımının “default deny + explicit allow” ile ilişkisini en doğru açıklayan seçenek hangisi?

A) Matriste yazmayan her akış otomatik olarak allow kabul edilir.

B) Matriste yazmayan akışlar reddedilir; yalnız matriste tanımlı ve gerekçeli akışlar dar izinle açılır.

C) Default deny yalnız internet trafiği için geçerlidir.

D) Explicit allow yalnız DMZ trafiğinde kullanılır.

E) Default deny, loglamayı gereksiz kılar.

Doğru: B
Gerekçe: Akış Matrisi “niyet belgesi”dir; niyet dışı trafik reddedilmelidir. C/D kapsam daraltması, A ters mantık, E ise kanıt üretimini zayıflatır.

Aşağıdaki kanıtlardan hangisi “policy drift” şüphesini en doğrudan güçlendirir?

A) PCAP’te TLS handshake görülmesi

B) Flow’da DMZ→internet uzun bağlantıların olması

C) Trafik davranışı değişmişken ilgili zaman penceresinde değişiklik kaydının olmaması

D) VLAN sayısının artmış olması

E) Wireshark’ta Expert Info uyarıları

Doğru: C
Gerekçe: Drift’in ayırt edici işareti niyet/kayıt ile gerçek davranışın ayrışmasıdır. Diğerleri tek başına drift’i doğrudan göstermez; bağlam ister.

Trunking için “allowed VLAN listesi çok geniş” bulgusunun operasyonel riski aşağıdakilerden hangisidir?

A) DNS çözümleme gecikmesi artar

B) Gereksiz VLAN’lar yanlış noktaya taşınarak bölge sınırlarını aşındırabilir ve görünürlük kör noktası oluşturabilir

C) TLS sertifikaları geçersiz olur

D) VPN tüneli düşer

E) NAC otomatik devre dışı kalır

Doğru: B
Gerekçe: Trunk’ta fazla VLAN taşıma, segmentasyon tasarımından sapma ve yanlış yerde yanlış VLAN görünürlüğü riskini artırır. Diğerleri bu bulguyla doğrudan ilişkili değildir.

DMZ tasarımında “DMZ’den iç ağa geniş allow” gözlemlendiğinde en doğru ilk yaklaşım hangisi?

A) Hemen tüm DMZ trafiğini kesmek

B) Önce kural export/diff ile hangi kuralın ALLOW ürettiğini belirlemek ve Akış Matrisi ile eşleştirmek

C) PCAP toplamadan karar vermek

D) Yalnız kullanıcı şikâyetlerini beklemek

E) Sadece VLAN konfigürasyonuna bakmak, firewall’ı incelememek

Doğru: B
Gerekçe: Kanıt-temelli yaklaşımda log→kural eşleme ve matrise uyum temel adımdır. A “do not harm” ilkesine aykırı kesinti riski, C/D/E eksik kanıt/yanlış öncelik.

“Kural gölgeleme (shadowing)” en iyi hangi durumda anlaşılır?

A) Aynı hedefe hem allow hem deny kuralı var ve deny üstte yer alır

B) Geniş bir allow kuralı, daha alttaki dar deny kuralının kapsadığı trafiği zaten allow ettiği için deny fiilen hiç çalışmıyordur

C) Flow logları yoktur

D) PCAP dosyası hash’lenmemiştir

E) VLAN sayısı azdır

Doğru: B
Gerekçe: Gölgeleme, kural sırası/öncelik yüzünden beklenen deny’nin hiç uygulanmamasıdır. Diğerleri kavramın tanımı değildir.

Zero Trust için aşağıdakilerden hangisi bu modülün kapsamına en uygun ifadedir?

A) Zero Trust, tek bir ürün satın alıp açmakla tamamlanır

B) Zero Trust, “iç ağ güvenlidir” varsayımını reddedip erişimi kimlik/cihaz/bağlam/policy ile doğrulamayı hedefleyen ilkeler setidir

C) Zero Trust yalnız Wi-Fi güvenliğidir

D) Zero Trust, VLAN’ları tamamen gereksiz kılar

E) Zero Trust, her şeyi bloklamaktır

Doğru: B
Gerekçe: Modül, ürün seçmeden kavramsal yaklaşımı öğretir. A/C/D/E ya indirger ya da yanlış genellemeler içerir.

“Tekil doğrulama testi (tarama değil)” ilkesine en uygun örnek hangisidir?

A) Bir subnet’te tüm portları denemek

B) Bir hedefte 1 port için bağlantı başarısını kontrol etmek (örn. 203.0.113.10:443)

C) İnternette rastgele hedefleri denemek

D) Çok sayıda hedefe paralel istek atmak

E) Kablosuz ağlarda şifre denemeleri yapmak

Doğru: B
Gerekçe: Tek hedef/tek port doğrulaması, segmentasyonun “izinli mi/izinsiz mi” hipotezini düşük riskle test eder. Diğerleri tarama/suistimal sınıfına girer.

Kanıt paketlemede hash manifest’in en temel amacı hangisidir?

A) Logların daha hızlı üretilmesi

B) Kanıt dosyalarının bütünlüğünü göstermek ve raporda izlenebilir referans sağlamak

C) VLAN etiketlerini görünür kılmak

D) TLS sertifikasını yenilemek

E) DMZ’yi otomatik oluşturmak

Doğru: B
Gerekçe: Hash/manifest, “kanıt değişmedi” iddiasını teknik olarak destekler. Diğerleri farklı konular.

Aşağıdakilerden hangisi “Akış Matrisi var ama erişim yok” durumunda en iyi yorumdur?

A) Kesin saldırı var

B) Mutlaka VLAN hopping olmuştur

C) İş kesintisi adayı olabilir: eksik kural, yanlış sıra, yanlış route veya servis kapalı; karşı kanıtla ayrıştırmak gerekir

D) Flow/PCAP gereksizdir

E) Sadece DMZ incelenmelidir

Doğru: C
Gerekçe: Matriste niyet var ama gerçek davranış yoksa önce “tasarım/politika/rota/servis” ayrıştırması gerekir. A/B aşırı kesin, D/E dar bakış.

Kapanış: Bu modülde kazandıkların

Segmentasyonun “tek cihazı güçlendirmekten” daha geniş etki yaratan mimari bir kontrol olduğunu ve blast radius’ü küçülttüğünü.
VLAN’ların güvenli bölgelemede güçlü bir araç olduğunu ama güvenlik sınırının çoğu zaman inter-VLAN politika ve görünürlükle tamamlandığını.
Trunking’in kavramsal risklerini (allowed VLAN genişliği, native VLAN tutarsızlığı, otomasyon/varsayılanlar, drift) kanıtla değerlendirmeyi.
DMZ’yi minimal, denetlenebilir akışlarla tasarlayıp DMZ→iç ağ riskini yönetmeyi.
Zero Trust’in “asla güvenme, her zaman doğrula” mantığını ürün seçmeden kavramsal düzeyde konumlandırmayı.
Akış Matrisi runbook’u ile doğrulama–kanıt–rollback disiplinini uçtan uca kurmayı.

MODÜL 5 — Güvenli Protokoller: TLS, VPN, 802.1X/NAC

Kavramsal şema: uygulama trafiğinin TLS ile sarılması; güvensiz omurga üzerinden VPN tüneli; portta 802.1X ile kimlik doğrulama ve RADIUS/NAC ile VLAN ve erişim kararı.

Bu modül, “şifreleme var” demenin tek başına güvenlik sağlamadığını; güvenliğin doğru yapılandırma + ölçülebilir kanıt + geri dönüş (rollback) disiplini ile ortaya çıktığını öğretir. TLS tarafında hedef; kilit ikonuna bakmak değil, sertifika zinciri, kimlik doğrulama, sürüm/şifre takımı politikası ve gözlemlenebilirliği birlikte değerlendirmektir. VPN tarafında hedef; “tünel kuruldu” cümlesini kimlik, cihaz duruşu (posture), rota/DNS davranışı, split/full-tunnel kararı ve log kanıtı ile doğrulanabilir hale getirmektir. 802.1X/NAC tarafında hedef; ağa giriş kontrolünü “port aç/kapat” seviyesinden çıkarıp kimlik + cihaz + bağlam temelli erişime taşımaktır. Tüm yaklaşım white-hat sınırlarındadır: yalnızca izinli/yerel ortam, düşük riskli doğrulama, kanıt üretimi; saldırı amaçlı tarama/istismar/bypass “how-to” yoktur.

Bu Dersin Hedefleri

TLS’i network gözünden “şifreleme + kimlik + politika” üçlüsüyle doğru yorumlar.
Sertifika zinciri (leaf–intermediate–root), kimlik (SAN/CN), geçerlilik ve iptal (CRL/OCSP) konularını kanıt standardında denetler.
VPN mimarilerini (site-to-site / remote access; IPsec / TLS tabanlı yaklaşımlar) risk–kontrol–kanıt mantığıyla değerlendirir.
Split-tunnel / full-tunnel kararını performans–risk dengesiyle gerekçelendirir; DNS/route sapmalarını kanıtlar.
802.1X’in (supplicant–authenticator–RADIUS) işleyişini, EAP yöntemleri ve operasyonel kesinti riskleriyle birlikte ele alır.
Denetim/okuma/kanıt üretimi için Windows/Linux/macOS komutları ve Wireshark/tcpdump/tshark okuryazarlığı kazanır.
3 çıktıyı üretir: TLS Sertifika Denetimi Runbook’u, VPN Duruş Kontrol Listesi, 802.1X/NAC Geçiş Planı (pilot + kademeli enforce + rollback).
Belirti → hipotez → kanıt → analiz → karar → rapor (Bulgu → Etki → Öneri → Kanıt) akışını bu protokollere uygular.

5.1 TLS ve sertifika mantığı (network gözünden)

TLS; istemci–sunucu iletişiminde gizlilik ve bütünlüğün yanında kimlik doğrulamayı hedefler. “Şifreli” olmanız, doğru uçla konuştuğunuzu otomatik kanıtlamaz. Network gözünden denetim, şifreleme + kimlik + politika + kanıt dörtlüsüyle yapılır.

Çekirdek mesaj

Kilit ikonu tek başına yeterli değildir; SAN/CN uyumu, zincir bütünlüğü, sürüm/cipher politikası ve gözlemlenebilir sinyaller birlikte okunur.

Görünürlük notu

Şifreli trafikte payload çoğu zaman görünmez; handshake, sertifika metadatası ve alert sınıfları operasyonel karar için kanıt çekirdeği üretir. SNI görünürlüğü tasarım ve politika konusudur.

Denetim bileşenleri

Bileşen	Ne sorulur?	Örnek kanıt / sinyal
Kimlik	SAN/CN, erişilen adla uyumlu mu?	hostname mismatch, uygulama logları
Zincir	Leaf doğru intermediate ile sunuluyor mu? Kök güveni standarda uygun mu?	Eksik intermediate, unknown_ca
Politika	TLS sürümü ve cipher suites kurum standardına uygun mu?	Handshake’ta seçilen sürüm/cipher, uyumluluk denetimi
Gözlemlenebilirlik	Drift ve hata sınıfları izlenebiliyor mu?	Alert türleri, fingerprint değişimi, LB/WAF değişiklik kaydı

Etki / risk (operasyonel sonuç)

Risk paterni	Operasyonel etki
Eksik/yanlış zincir	Bağlantı kesintileri; “geçici ignore” refleksi kalıcı risk üretir.
Zayıf politika (eski sürüm/cipher)	Uyumsuzluk; veri gizliliği/bütünlüğü riski; istemci uyumsuzluğu.
İptal görünmezliği	Ele geçirilmiş sertifikanın geçerli sanılması.
Yaşam döngüsü boşluğu	Süre dolumu → availability kesintisi; “unutulan sertifika” olayı.

Tespit sinyali / kanıt (log / flow / pcap)

Uygulama logları: certificate verify failed, unknown_ca, hostname mismatch, handshake_failure sınıfları.
PCAP (handshake): ClientHello/ServerHello, Certificate, Alerts; sürüm/cipher; parmak izi değişimleri.
İstemci OS: TLS doğrulama hataları (ör. Schannel vb.).
Değişiklik kayıtları: LB/WAF/reverse proxy policy drift için.

Savunma kontrolü / düzeltme

Kimlik hijyeni: SAN uyumu + servis adı standardı.
Zincir: Intermediate eksikliği sık kök nedendir; doğru zincir + kurum kök deposu uyumu.
Politika: Kurum TLS standardı sürüm/cipher seviyesinde tanımlanır ve denetlenir (NIST TLS rehberleri referans çerçeve).
Yaşam döngüsü: Bitişe X gün kala uyarı, otomasyon, rollback planı.

Bypass / erişim farkındalığı (yalnızca savunma)

Kategori: hatalı TLS duruşu (yanlış kimlik, eksik chain, zayıf politika). Amaç (kavramsal): kimlik doğrulamayı zayıflatıp yanıltma veya arada konumlanma etkisi aramak. Beklenen iz: handshake alert’leri, beklenmedik fingerprint değişimi, policy drift. Savunma: sertifika denetimi, CA politikası/pinning yaklaşımı, change management, izleme. Örnek kanıt (uydurma): aynı serviste 24 saat içinde SHA-256 fingerprint değişimi + eş zamanlı unknown_ca artışı.

5.2 VPN mimarileri

VPN; güvenilmeyen ağlar üzerinden kuruma erişimde “tünel” kavramını kimlik + yetki + görünürlük ile birleştiren bir kontrol setidir. Hedef, “tünel kuruldu” cümlesini kanıtlanabilir duruş (posture, rota, DNS, log) ile doğrulamaktır.

Site-to-site

Şube–merkez gibi iki ağı bağlar; ağlar arası yönlendirme ve politika kritikleşir.

Remote access

Kullanıcı cihazını kuruma bağlar; kimlik ve cihaz duruşu daha belirleyicidir.

Mimari çeşitleri (özet)

Yaklaşım	Odak	Operasyonel not
IPsec tabanlı	Ağ katmanı tünel, politika parametreleri	NIST IPsec VPN rehberleri referans çerçeve sunar; log ve kimlik disiplini şart.
TLS tabanlı (SSL VPN sınıfı)	Uygulama/TLS katmanı uzaktan erişim	NIST SSL VPN rehberi risk ve güvenlik hususlarını tartışır.
Modern / sade tasarımlar	Performans ve operasyon	Kurum standardı yine kimlik, duruş ve log ile tamamlanmalıdır.

Etki / risk

Risk	Sonuç
Zayıf kimlik (MFA yok, paylaşılan hesap)	Uzaktan erişim “en kısa yol” haline gelir.
Split tunneling yanlış yönetimi	DNS sızıntısı / yanlış rota; erişim ve veri yönlendirme riski.
Aşırı yetkili profil	“Kurum içi gibi” geniş erişim; segmentasyon bypass riski.
Loglama eksikliği	Kim, ne zaman, nereden, hangi profille, hangi kaynağa — cevaplanamaz.

Tespit sinyali / kanıt

Gateway logları: başarılı/başarısız giriş, MFA, atanan IP/pool, profil/policy, oturum süresi.
İstemci: VPN bağlı ama kaynak yok → rota/DNS/policy sinyali.
Flow/PCAP (hedefli): VPN havuzu → iç segment; beklenmedik hedef/port drift.

Savunma kontrolü / düzeltme

Duruş kanıtı: kimlik + cihaz uyumu + doğru profil + rota/DNS doğrulaması birlikte.
Yetki minimizasyonu: profiller segmente göre daraltılır; “her yere erişim” varsayılan olmamalı.
İstisna yaşam döngüsü: split-tunnel istisnaları owner + gerekçe + expiry ile.

Bypass / erişim farkındalığı (yalnızca savunma)

Kategori: aşırı izinli profil, zayıf duruş, yanlış split-tunnel. Amaç (kavramsal): “kurum içi gibi” görünmek ve kapsam genişletmek. Beklenen iz: çoklu oturum, olağandışı ülke/cihaz, beklenmedik iç hedef akışı. Savunma: MFA, posture, profil daraltma, anomali izleme, kayıt disiplini. Örnek kanıt (uydurma): VPN-POOL-1 → APP-ZONE TCP/8443 akışının genel kullanıcı profilinde gerekçesiz görünmesi.

5.3 802.1X / RADIUS / EAP

802.1X, ağa erişimi “takıldı → erişti” çizgisinden çıkarıp kimlik doğrulamalı port erişimi haline getirir. EAP, farklı kimlik yöntemlerini taşıyan çerçevedir; EAP-TLS sertifika tabanlı karşılıklı doğrulamayı hedefler (RFC’ler). Parola tabanlı yöntemler operasyonel kolaylık sağlar; risk profili farklıdır.

Üç rol (802.1X)

Rol	Bileşen	Görev
Supplicant	PC, telefon	Kimlik bilgisini sunar.
Authenticator	Switch, AP	Portu yönetir; EAPOL taşır.
Authentication Server	RADIUS	Karar (Accept/Reject) ve politikayı besler.

Güçlü taraf

Kimlik + cihaz temelli kontrol; misafir/karantina VLAN; dinamik politika; “kim nerede” görünürlüğü.

Operasyonel risk

Yanlış politika geniş kesinti; sertifika yaşam döngüsü boşluğunda toplu düşüş riski.

Etki / risk

İstisna genişlemesi: IoT/legacy için istisna gerekir; tasarım zayıfsa kontrolün anlamı kırılır.
MAC tabanlı geçiş: operasyonel araç olarak konuşulabilir; güvenlik düşük, kalıcı çözüm gibi bırakılmamalı (taklit edilebilir kimlik).
Yetkilendirme ayrımı: “Doğrulandı” ≠ “doğru VLAN/rol/policy”; eşleme ayrı kanıtlanır.

Tespit sinyali / kanıt

RADIUS: Access-Accept/Reject, neden kodları, sertifika hataları, timeout.
İstemci: EAP hataları, saat/CRL, güven zinciri sorunları.
PCAP: EAPOL (istemci–AP/switch), RADIUS (AP–sunucu); kimlik doğrulama zaman çizelgesi.

Savunma kontrolü / düzeltme

Kademeli geçiş: monitor → pilot → kademeli enforce → sertleşme.
Sertifika: CA zinciri, dağıtım/yenileme, CRL/OCSP erişilebilirliği.
İstisna: kısıtlı VLAN + dar egress + yoğun log + süreli onay.

Bypass / erişim farkındalığı (yalnızca savunma)

Kategori: zayıf EAP, sertifika yaşam döngüsü boşluğu, geniş istisna. Amaç (kavramsal): meşru cihaz gibi görünmek. Beklenen iz: tekrarlayan Reject, aynı kimlikte farklı cihaz davranışı, beklenmedik VLAN. Savunma: EAP-TLS, sertifika hijyeni, istisna yaşam döngüsü, korelasyon. Örnek kanıt (uydurma): 5 dakikada 40× Access-Reject (unknown_ca) + istisna VLAN’a düşen cihaz artışı.

5.4 Denetim/okuma araçları

Bu başlık, “konfigürasyonu görüyorum” ile kanıt üretiyorum arasındaki farkı kapatır. Araç çıktısı tek başına değerlidir; asıl değer, çıktıyı politika ve hipotezle eşleyip drift yakalamaktır.

Alan bazlı kanıt odağı

Alan	Kanıt paketinde ne olur?
TLS	Sertifika çıkarımı, handshake kesiti, hata sınıfları (uygulama + istemci).
VPN	Profil/policy, oturum logları, rota ve DNS çıktıları.
802.1X	RADIUS karar kayıtları; gerektiğinde EAPOL/RADIUS paket kanıtı.

Otomasyon (izinli)

Tek servis için cipher envanteri çıkaran scriptler kullanılabilir; yalnızca izinli denetim ve değişiklik yönetimiyle. Drift’i yakalamak için yorum şart.

Risk

Araç okuryazarlığı zayıfsa TLS / DNS / VPN / 802.1X karışır; yanlış düzeltme daha büyük kesinti doğurur. Kanıt yoksa drift kronikleşir.

Savunma disiplini

Tekil doğrulama: tek hedef / tek servis; düşük yoğunluk; tarama yok.
Kanıt paketleme: zaman damgası + çıktı dosyaları + kısa analiz notu + hash manifest.

5.5 Komut & Araç Okuryazarlığı (Denetim / Doğrulama / Kanıt)

Aşağıdaki komutlar yalnızca izinli/yerel denetim ve güvenli doğrulama içindir. Amaç saldırı değil; TLS, VPN ve 802.1X duruşunu kanıtlamak ve olay ayrıştırmaktır.

Tekil doğrulama

Tek hedef, tek servis, düşük yoğunluk; tarama ve geniş kapsamlı keşif yok.

Çıktı disiplini

Her komut çıktısı evidence/ altında dosyalanır; raporda hipotez ve zaman penceresi notu bulunur.

Ortak kanıt disiplini (mini şablon)

1. Zaman damgası al.
2. Çıktıyı dosyala.
3. notes/ altına hangi hipotezi test ettiğini yaz.
4. Hash manifest üret.

Örnek terminal oturumları (kavramsal)

Aşağıdaki kutular tipik kanıt çıktısı görünümünü simüle eder; IP ve metinler örnektir.

Windows PowerShell

PowerShell — kanıt hizalama

PS C:\YYYYMMDD_mod5\evidence> Get-Date -Format o | Write-Output 2026-04-17T14:22:11.1234567+03:00 PS C:\YYYYMMDD_mod5\evidence> Test-NetConnection -ComputerName 203.0.113.10 -Port 443 | Select-Object TcpTestSucceeded TcpTestSucceeded : True # False ise servis/policy ayrımı için log/PCAP ile karşı kanıt.

Linux

bash — TLS kanıt satırı

analist@host:~/evidence$ grep -E "Verify return code|subject=|issuer=" openssl_s_client_203_0_113_10_443.txt subject=CN = example.org issuer=C = US, O = Example CA Verify return code: 0 (ok) # 0 değilse unknown_ca / hostname vb. satırları notes/ ile eşle.

macOS

Terminal — resolver

analist@MacBook evidence % scutil --dns | head -n 14 resolver #1 nameserver[0] : 192.0.2.53 # VPN sonrası iç FQDN beklenen resolver’da mı kontrol et.

Windows (PowerShell)

Zaman damgası (kanıt hizalama)

Get-Date -Format o | Out-File .\evidence\time.txt

Amaç: kanıtları tek zaman referansına bağlamak.
Beklenen: ISO 8601 zaman satırı. Not: UTC/yerel farkını yaz.
Sınır: okuma/kanıt.

TLS — sertifika deposu envanteri (LocalMachine\My)

Get-ChildItem Cert:\LocalMachine\My |
Select-Object Subject, Issuer, NotBefore, NotAfter, Thumbprint |
Out-File .\evidence\cert_localmachine_my.txt

Amaç: kimlik, süre, thumbprint envanteri.
Yorum: thumbprint değişimi sertifika drift sinyalidir.
Sınır: okuma.

TLS — tekil servis bağlantısı (tarama değil)

Test-NetConnection -ComputerName 203.0.113.10 -Port 443 |
Out-File .\evidence\tnc_203_0_113_10_443.txt

Beklenen: TcpTestSucceeded True/False.
False ise: policy mi servis mi — sunucu log/PCAP ile karşı kanıt.
Sınır: tek hedef/tek port.

VPN — yerel profiller

Get-VpnConnection |
Select-Object Name, ServerAddress, SplitTunneling, TunnelType |
Out-File .\evidence\vpn_profiles.txt

Yorum: SplitTunneling açıksa istisna yaşam döngüsü kanıtı gerekir.

802.1X (Wi-Fi) — profil listesi (varsa)

netsh wlan show profiles > .\evidence\wlan_profiles.txt

Not: asıl kanıt RADIUS + istemci olaylarıyla tamamlanır.

Kanıt bütünlüğü — SHA-256

Get-FileHash .\evidence\* -Algorithm SHA256 | Out-File .\manifest.sha256

Sınır: okuma/kanıt; raporda manifest referansı ver.

Linux (bash)

Komut akışı

Zaman → openssl s_client → gerektiğinde openssl x509 → rota/DNS → (gerekirse) NetworkManager log → kısa PCAP → hash.

Zaman (UTC)

date -u +"%Y-%m-%dT%H:%M:%SZ" | tee evidence/time_utc.txt

Amaç: log/pcap korelasyonu. Not: saat kayması sertifika ve EAP’te sık kök nedendir.

TLS — tekil hedef sertifika + handshake

openssl s_client -connect 203.0.113.10:443 -servername example.org -showcerts </dev/null \
2>&1 | tee evidence/openssl_s_client_203_0_113_10_443.txt

Beklenen: zincir + Verify return code + handshake. Ara: verify error, eksik intermediate, hostname uyumsuzluğu.
Sınır: tek hedef/tek servis.

TLS — sertifika alanları (ayrıştırma)

awk '/BEGIN CERTIFICATE/{i++}{print > ("evidence/cert_"i".pem")}' evidence/openssl_s_client_203_0_113_10_443.txt
openssl x509 -in evidence/cert_1.pem -noout -subject -issuer -dates -serial -fingerprint -sha256 \
| tee evidence/cert_1_parsed.txt

Beklenen: Subject/Issuer/NotBefore/NotAfter/Serial/Fingerprint. SAN için gerekirse -text (yalnızca denetim).

VPN sonrası rota + DNS

ip route show | tee evidence/ip_route.txt
resolvectl status 2>/dev/null | tee evidence/resolvectl_status.txt

Not: iç FQDN beklenmeyen resolver’a gidiyorsa VPN bağlı olsa bile erişim kırılabilir.

802.1X — istemci log (örnek)

journalctl -u NetworkManager --since "1 hour ago" | tee evidence/nm_last1h.txt

PCAP — kısa, sınırlı

sudo tcpdump -nn -i eth0 host 203.0.113.10 and tcp port 443 -c 200 -w evidence/tls_handshake_sample.pcap

Sınır: kısa süre, tek hedef, izinli ortam.

Hash manifest

sha256sum evidence/* | tee manifest.sha256

macOS

Komut akışı

Zaman (UTC)

date -u +"%Y-%m-%dT%H:%M:%SZ" | tee evidence/time_utc.txt

Linux ile aynı amaç ve güvenli sınır.

TLS — s_client

openssl s_client -connect 203.0.113.10:443 -servername example.org -showcerts </dev/null \
2>&1 | tee evidence/openssl_s_client_203_0_113_10_443.txt

Sistem güven kökleri (okuma)

security find-certificate -a -p /Library/Keychains/System.keychain > evidence/system_certs.pem

Rota + DNS

netstat -rn | tee evidence/netstat_route.txt
scutil --dns | tee evidence/scutil_dns.txt

Hash

shasum -a 256 evidence/* | tee manifest.sha256

Wireshark / tshark okuryazarlığı

Capture stratejisi

Önce soruyu sabitle: hata TLS mi, VPN policy mi, 802.1X kararı mı?
TLS: tek hedef/443, 60–120 sn; yalnızca handshake kanıtı.
802.1X: istemci tarafında EAPOL; mümkünse authenticator–RADIUS ile zaman eşleme.
VPN: tünel sonrası erişim anı + route/DNS çıktısı ile korelasyon.
Ring buffer: disk şişmesini önler; kanıt dosyası yönetimini kolaylaştırır.

Kanıta çevirme

Statistics → Protocol Hierarchy / Conversations / Endpoints: kim kiminle, hangi pencerede?
TLS: handshake paketlerini işaretle → kısa kesit + ekran görüntüsü + notes/.
802.1X: EAPOL kesiti + RADIUS log satırı ile zaman eşlemesi.
Her pakete SHA-256 manifest.

Odak	Display / filtre ipuçları
TLS el sıkışma	`tls.handshake`
Belirli hedef	`ip.addr == 203.0.113.10 && tcp.port == 443`
TLS uyarıları	`tls.alert_message`
EAPOL	`eapol`
RADIUS	`radius`

TLS okurken: sürüm/cipher, sertifika mesajı, alert tipi.
802.1X okurken: EAPOL’de istek/yanıt/kesinti; RADIUS’ta Accept/Reject ve zaman uyumu.

tshark — örnek kesitler (kavramsal)

Kayıtlı PCAP üzerinde yalnız izinli analiz; filtreleri hedef ve zaman penceresine dar tut.

tshark — TLS handshake satırları

analist@host:~/evidence$ tshark -r tls_handshake_sample.pcap -Y "tls.handshake.type == 1 || tls.handshake.type == 2" -T fields -e frame.time -e tls.handshake.type | head -n 4 Apr 17, 2026 14:22:01.045 1 Apr 17, 2026 14:22:01.112 2 # 1=ClientHello, 2=ServerHello; sürüm/cipher için paket detayına geç.

tshark — EAPOL varlığı

analist@host:~/evidence$ tshark -r eapol_sample.pcap -Y "eapol" -c 6 1 0.000000 aa:bb:cc:dd:ee:ff → Broadcast EAPOL ... # RADIUS bacağı ayrı dosyada ise zaman damgasıyla eşle.

5.6 HOW-TO: TLS Sertifika Denetimi (Kanıt Standardında)

Amaç: tek bir servis uç noktasının TLS duruşunu tek hedef / tek servis kuralıyla kanıtlanabilir hale getirmek.

Hazırlık — kapsam

Alan	Değer (örnek)
Uç nokta	example.org (uydurma) / IP: 203.0.113.10
Servis	443/TCP
Zaman penceresi	“şu an” + son 7 gün uygulama logları
Kanıt dizini	`YYYYMMDD_mod5_tls_audit/` → `evidence/`, `notes/`, `manifest.sha256`

Kontrol kriterleri

Kimlik (SAN), zincir (intermediate), süre (NotBefore/NotAfter), issuer tutarlılığı.
İptal görünürlüğü (kurum politikası bağlamında).
TLS sürüm/cipher politikası (kurum standardı).

Uygulama (denetim / okuma)

Adım	Eylem
1	Sertifikayı ve zinciri çıkar → dosyala (`openssl s_client` çıktısı).
2	Alanları yorumla: SAN beklenen adı içeriyor mu? NotBefore/NotAfter ve seri/issuer tutarlı mı? Zincir eksiksiz mi?
3	Handshake kanıtı: istemci çıktısı + (varsa) sunucu log kesiti.
4	Drift: fingerprint ve seri önceki denetimlerle değişmiş mi?

Doğrulama (güvenli)

Tekil test: bağlantı kuruluyor mu, sertifika doğrulaması geçiyor mu?
Karşı kanıt: bağlantı yoksa servis kesintisi mi TLS doğrulama mı — aynı hedefte TLS katmanını gösteren kanıtlar.

Minimum kanıt seti

PEM/chain çıktısı; timestamp’li komut çıktıları.
(Varsa) yalnız handshake içeren kısa PCAP + ekran görüntüsü.
manifest.sha256 + notes/ (hipotez ve sonuç).

Örnek terminal — zincir doğrulama satırı

bash — Verify return code

analist@host:~/YYYYMMDD_mod5_tls_audit/evidence$ tail -n 8 openssl_s_client_203_0_113_10_443.txt SSL handshake has read 3120 bytes and written 430 bytes Verification: OK --- Verify return code: 0 (ok) # 0 değilse aynı dosyada "verify error" / chain satırlarını rapora bağla.

Geri dönüş / rollback

Sertifika/policy değişikliğinde eski yapılandırmaya dönüş adımları değişiklik prosedüründe hazır olmalı.
Rollback tetikleri: doğrulama hatası artışı, kritik istemcilerde kesinti, hata oranı eşiği aşımı.

5.7 HOW-TO: VPN Duruş (Posture) Kontrol Listesi

Amaç: VPN’i yalnızca “erişim kanalı” değil, kanıtlanabilir güvenlik kontrolü (kimlik, posture, rota/DNS, log) olarak değerlendirmek.

Hazırlık

Öğe	Tanım
Kapsam	(a) remote access profili, (b) örnek kullanıcı grubu, (c) örnek uygulama erişimi
Kanıt kaynakları	Gateway logları, istemci durum çıktıları, DNS/route, MFA kayıtları
Politika hedefi	Minimum erişim + güçlü kimlik + cihaz duruşu + görünürlük

Checklist (uygulama)

Alan	Sorular
A) Kimlik ve oturum	MFA zorunlu mu? Başarısız deneme kilidi/ratelimit var mı? Oturum ve idle timeout tanımlı mı?
B) Posture	Yönetimli cihaz (MDM/EDR)? Disk şifreleme, ekran kilidi? Uyumsuzlukta reddetme mi karantina profili mi?
C) Rota / DNS / tünel	Split tunneling açık mı; istisnalar owner/expiry ile mi? İç FQDN DNS’i doğru mu; sızıntı sinyali var mı? Profil segmente göre dar mı?
D) Kripto / politika	Kurum standardı, değişiklik kaydı, loglama yeterliliği (ürüne göre).
E) Loglama ve kanıt	“Kim, ne zaman, nereden, hangi profille, hangi iç kaynağa?” cevaplanıyor mu? Örnek paket: giriş + atanan IP + profil + flow/log kesiti + manifest.

Doğrulama (güvenli)

Tekil test: seçili tek iç uygulamaya erişim ve beklenen log izi.
Karşı kanıt: erişim yoksa route/DNS ile katman ayrıştırması.

Kanıt paketleme ve rollback

Paket: gateway log kesiti + istemci route/DNS + manifest + kısa analiz notu.
Yayın: değişiklikler küçük kapsamla.
Rollback: bağlantı hata oranı artışı veya kritik uygulamada erişim düşüşü.

Örnek terminal — profil ve rota (kavramsal)

Windows

PowerShell — VPN profili

PS C:\evidence> Get-VpnConnection | Select-Object Name, ServerAddress, SplitTunneling, TunnelType | Format-Table Name ServerAddress SplitTunneling TunnelType CorpVPN vpn.example.corp False IKEv2 # Gateway log ile profil adı ve oturum zamanını eşle.

Linux

bash — rota özeti

analist@host:~/evidence$ ip route show | head -n 6 default via 192.0.2.1 dev tun0 metric 50 10.0.0.0/8 via 192.0.2.1 dev tun0 # İç uygulama erişimi yoksa DNS ve split tunnel notu ile birlikte oku.

5.8 HOW-TO: 802.1X/NAC Geçiş Planı

Amaç: “bir gecede enforce” yerine ölç → kanıtla → kademeli sıkılaştır ile 802.1X/NAC devreye almak.

Hazırlık

Envanter: kurumsal PC, BYOD, yazıcı/IoT, özel gruplar; 802.1X uyumluluk durumu.
Yöntem: EAP çerçevesi ve yöntem riski (EAP-TLS güçlü; sertifika yaşam döngüsü ister).
RADIUS: yedeklilik, loglama, NTP, sertifika zinciri planı.

Politika çıktısı (hedef görünüm)

Durum	Çıktı
Başarılı doğrulama	Üretim VLAN / rol bazlı policy
Başarısız	Misafir/karantina VLAN (kısıtlı)
İstisna	Owner + gerekçe + expiry + dar erişim + yoğun log

Aşamalı uygulama

Faz	Ne yapılır?
1 — Monitor	Karar logları toplanır; kesinti yok.
2 — Pilot	Seçili kullanıcı grubu + seçili lokasyon.
3 — Kademeli enforce	Lokasyon/departman bazlı yayılım.
4 — Sertleşme	İstisna azaltma, karantina sıkılaştırma, kök neden kapatma.

Doğrulama (güvenli)

Başarı: Reject oranı eşik altında; yanlış VLAN yok; olay hacmi yönetilebilir.
Kanıt: Access-Accept/Reject örnekleri + istemci log + (varsa) kısa EAPOL/RADIUS PCAP + manifest.

Geri dönüş / rollback

Tetik: geniş kesinti veya kritik grupta ani Reject artışı.
Eylem: enforce geri al → monitor → kök neden kapanmadan tekrar enforce etme.

Örnek terminal — istemci EAP izi (kavramsal)

journalctl — 802.1X / EAP satırları

5.9 Operasyonel Senaryo

Senaryo: Pilot 802.1X (EAP-TLS) sonrası erişim kesintisi — sertifika mı, zaman mı, yetkilendirme mi?

Belirti

Pilot lokasyonda enforce sonrası bazı dizüstüler ağa bağlanamıyor; bazı cihazlar karantina VLAN’a düşmüş gibi; kullanıcılar “internete çıkmıyor” diyor. Bu gözlemdir; hüküm değildir.

Hipotezler (önceliklendir)

#	Hipotez
1	RADIUS’ta zincir istemcide güvenilmiyor (`unknown_ca` / eksik chain).
2	İstemci saat kayması nedeniyle sertifika “henüz geçerli değil / süresi dolmuş” görünüyor.
3	Kimlik doğrulama başarılı ama VLAN/ACL/rol yanlış; karantina veya yanlış policy.
4	Karşı hipotez: asıl sorun DHCP/route; 802.1X’e yanlış atıf.

Minimum kanıt seti

RADIUS: Access-Accept/Reject + neden alanı.
İstemci: EAP-TLS doğrulama hata sınıfı.
Kısa PCAP: EAPOL (istemci portu) + mümkünse RADIUS bacağı.
Zaman damgası + hash manifest; (varsa) switch port auth log.

Örnek terminal — log satırları (kavramsal)

grep — RADIUS karar kesiti (örnek)

analist@host:~/pilot_evidence$ grep -E "Access-Reject|TLS-Client-Cert|TLS error" radius_pilot.log | tail -n 3 Apr 17 14:18:02 radius1 ... Access-Reject for user host/laptop01 ... TLS certificate chain invalid analist@host:~/pilot_evidence$ date -u +"%Y-%m-%dT%H:%M:%SZ" 2026-04-17T11:18:05Z # İstemci saatı ile NotBefore/NotAfter kıyasını notes/ altında yaz.

Analiz adımları

Adım	Soru / eylem
1	RADIUS kararı: Reject mi Accept? Reject ise neden (log satırı)?
2	`unknown_ca` / cert verify failed varsa RADIUS zincir kanıtı + istemci kök deposu uyumu.
3	İstemci UTC zaman kanıtı; NotBefore/NotAfter ile karşılaştır.
4	Accept var ama erişim yoksa VLAN/rol/policy kanıtı; doğrulama ≠ yetkilendirme ayrımı.
5	Karşı kanıt: prosedüre uygun, düşük etkili kontrolle katman ayrıştırması (kesinti üretmek için değil).

Karar ağacı (özet)

Reject + cert hatası: zinciri ve CA dağıtımını düzelt; pilotu tekrarla.
Accept + yanlış VLAN/policy: rol eşlemesi; karantina/üretim ayrımı; rollback kriterleri.
Belirsizlik: kesin kök neden demeden log + PCAP + zaman eşlemesi ile güçlendir.

Rapor iskelesi (Bulgu → Etki → Öneri → Kanıt)

Bulgu (örnek): EAP-TLS’te certificate validation failed / unknown_ca ile Access-Reject artışı. Etki: kesinti; “geçici istisna” baskısı ve güvenlik düşüşü riski. Öneri: zincir ve kök güven standardizasyonu; Accept/Reject–VLAN korelasyon görünürlüğü; küçük pilot; rollback eşikleri. Kanıt: RADIUS + istemci log + EAPOL PCAP özeti + zaman + manifest.

Terimler Sözlüğü (Glossary)

Terim Türkçe karşılığı / açıklama

TLS İstemci–sunucu iletişimini şifreleme ve kimlik doğrulama ile koruyan protokol.

Sertifika Zinciri Leaf sertifikanın intermediate ve root CA üzerinden doğrulanma yolu.

CA (Certificate Authority) Sertifikaları imzalayan güvenilir otorite.

SAN Subject Alternative Name; sertifikanın hangi adlar için geçerli olduğunu belirtir.

Revocation Sertifika iptali; CRL/OCSP gibi mekanizmalarla kontrol edilir.

VPN Güvenilmeyen ağ üzerinden güvenli tünel ile erişim sağlayan mimari yaklaşım.

IPsec Ağ katmanında (IP seviyesinde) tünelleme/koruma sağlayan protokol ailesi.

SSL VPN (TLS tabanlı VPN) TLS üzerinden uzaktan erişim sağlayan VPN ürün sınıfı yaklaşımı.

802.1X Port tabanlı kimlik doğrulamalı ağ erişim kontrol standardı.

Supplicant 802.1X istemcisi (uç cihaz).

Authenticator Switch/AP gibi, portu kontrol eden bileşen.

RADIUS AAA (kimlik doğrulama/yetkilendirme/kayıt) kararlarını taşıyan protokol.

EAP Birden çok kimlik doğrulama yöntemini taşıyan çerçeve.

EAP-TLS Sertifika tabanlı karşılıklı doğrulama sağlayan EAP yöntemi.

Posture Cihazın güvenlik duruşu/uyum durumu (MDM/EDR, disk şifreleme vb.).

Split Tunneling VPN’de sadece kurum trafiğinin tünelden gitmesi; diğer trafiğin yerel çıkması.

Full Tunnel VPN’de tüm trafiğin tünel üzerinden yönlenmesi.

Kendini Değerlendir

Aşağıdaki sorular, ezber değil; kanıt okuryazarlığı, yöntem seçimi ve karşı kanıt düşünmesini ölçer.

TLS denetiminde “kimlik doğrulama” başarısızlığını en doğrudan kanıtlayan set hangisidir?

A) ping çıktısı + traceroute

B) Uygulama logunda unknown_ca + handshake PCAP’inde TLS Alert + sertifika fingerprint kaydı

C) CPU/RAM grafikleri + disk kullanımı

D) DNS cache çıktısı + ARP tablosu

E) Flow verisinde yüksek throughput

Doğru: B
Gerekçe: Kimlik doğrulama hatası TLS katmanında log + alert + sertifika kanıtıyla doğrulanır. Diğerleri dolaylı veya alakasızdır.

“VPN bağlı ama iç uygulama açılmıyor” belirtisinde en doğru ilk ayrıştırma yaklaşımı hangisidir?

A) Hemen tüm iç ağa geniş kapsamlı port taraması yapmak

B) Tekil hedefe erişim denemesi + istemci route/DNS çıktısı + gateway log zaman eşleme

C) VPN’i kapatıp açmak ve raporlamadan bırakmak

D) Kullanıcının parolasını sıfırlamak (kanıt toplamadan)

E) Tüm firewall kurallarını geçici olarak allow-all yapmak

Doğru: B
Gerekçe: “Bağlı” durumu yetmez; rota/DNS/policy/log kanıtı ile sorun katmanı ayrıştırılır. A/E zararlı ve kapsam dışıdır; C/D kanıtsızdır.

802.1X geçişinde en riskli operasyonel hata hangisidir?

A) Pilot yapmak

B) Monitor modda log toplamak

C) Sertifika yaşam döngüsü/yenileme planı olmadan geniş çapta enforce açmak

D) NTP zaman senkronunu kontrol etmek

E) Karantina VLAN tanımlamak

Doğru: C
Gerekçe: Sertifika/kimlik altyapısı hazır değilse “bir sabah herkes düşer” kesintisi doğar. Diğerleri risk azaltıcıdır.

TLS politikasında drift şüphesinde “en az riskli ve en kanıtlanabilir” yaklaşım hangisidir?

A) Üretim trafiğini toplu şekilde decrypt etmeye çalışmak

B) Tek servis/tek hedef handshake kanıtı + sertifika fingerprint karşılaştırması + değişiklik kaydı korelasyonu

C) Rastgele kullanıcı cihazlarında deneme-yanılma

D) Tüm sertifikaları aynı gün değiştirmek (kanıt toplamadan)

E) Sadece “kilit ikonu var” diye rapor yazmak

Doğru: B
Gerekçe: Drift, en temiz şekilde tekil handshake + fingerprint + change log korelasyonuyla yakalanır. A yüksek riskli; diğerleri kanıtsızdır.

Split tunneling istisnaları için doğru yönetişim seti hangisidir?

A) “Süresiz, gerekçesiz, herkes için açık”

B) Owner + gerekçe + expiry + segment bazlı dar erişim + log korelasyonu

C) Sadece performans ölçümü

D) Kullanıcı isteğine göre anlık değiştir

E) Log tutma zorunlu değil

Doğru: B
Gerekçe: İstisna yönetimi yaşam döngüsü ve görünürlük ister; aksi drift ve risk büyütür.

RADIUS’ta Access-Accept görünüyor ama kullanıcı karantina VLAN’a düşüyor. En olası sınıf hangisidir?

A) TLS handshake sorunu

B) Yetkilendirme/policy eşlemesi (rol/VLAN ataması) hatası

C) Disk doluluğu

D) DNS cache bozulması

E) Tarayıcı eklentisi

Doğru: B
Gerekçe: Doğrulama (Accept) ile yetkilendirme (VLAN/policy) ayrıdır; Accept varken yanlış VLAN tipik policy eşlemesidir.

“Sertifika süresi doldu” olayını erken yakalamanın en doğru kontrol yaklaşımı hangisidir?

A) Kullanıcı şikâyetlerini beklemek

B) Sertifika bitimine X gün kala uyarı + düzenli denetim kanıtları + değişiklik/yenileme prosedürü

C) Sadece firewall loglarına bakmak

D) VPN’i kapatmak

E) 802.1X’i devre dışı bırakmak

Doğru: B
Gerekçe: Yaşam döngüsü yönetimi ölçüm/uyarı/prosedürle olur; diğerleri alakasız veya reaktiftir.

Wireshark’ta TLS sorununu kanıta dönüştürmek için en iyi minimal çıktı hangisidir?

A) Tüm günün PCAP’i (sınırsız)

B) Sadece handshake paketleri + ilgili alert + ekran görüntüsü + hash manifest + kısa not

C) Sadece “Protocol Hierarchy” ekran görüntüsü

D) Sadece ping sonucu

E) Tüm ağın endpoint listesi

Doğru: B
Gerekçe: Minimal, hedefli ve izlenebilir kanıt seti; A aşırı ve riskli, diğerleri yetersiz.

802.1X desteklemeyen cihazlar için istisna verilecekse, savunma açısından en doğru yaklaşım hangisidir?

A) Sınırsız erişim + log tutma yok

B) Kısıtlı VLAN + dar egress + yoğun loglama + süreli onay + kalıcı çözüm planı

C) Aynı kullanıcı kimliğiyle tüm cihazları geçir

D) “Sonra bakarız”

E) VPN’e alıp her yere aç

Doğru: B
Gerekçe: İstisna güvenlik seviyesini düşürür; risk azaltıcı sınırlar ve yaşam döngüsü şarttır.

Aşağıdaki kanıt zincirlerinden hangisi “Belirti → Hipotez → Karşı kanıt” disiplinini en iyi gösterir?

A) Belirti: erişim yok → Hipotez: saldırı var → Kanıt: yok

B) Belirti: VPN bağlı ama uygulama yok → Hipotez: DNS sapması → Kanıt: scutil/resolvectl + gateway log → Karşı kanıt: aynı anda route doğruysa DNS dışı kök neden arama

C) Belirti: TLS uyarısı → Hipotez: sunucu bozuk → Kanıt: yok → Karşı kanıt: yok

D) Belirti: 802.1X Reject → Hipotez: kullanıcı hatası → Kanıt: kullanıcı beyanı

E) Belirti: yavaşlık → Hipotez: TLS → Kanıt: CPU grafiği

Doğru: B
Gerekçe: Somut kanıt + alternatif açıklamayı çürütecek/ayıracak karşı kanıt düşüncesi var. Diğerleri kanıtsız veya yanlış katmanda.

Bu modülde neler öğrendik?

TLS’in yalnızca “şifreleme” değil; kimlik + zincir + politika olduğunu ve bunu kanıtla denetlemeyi.
Tek hedef/tek servis yaklaşımıyla TLS sertifika denetimini kanıt standardında üretmeyi.
VPN’de başarı ölçütünün “tünel kuruldu” değil; kimlik + posture + rota/DNS + log bütünlüğü olduğunu.
802.1X’te doğrulama–yetkilendirme ayrımını, RADIUS/EAP kararlarını log/pcap ile kanıtlamayı.
Wireshark/tcpdump ile handshake ve EAPOL/RADIUS sinyallerini okuyup raporlanabilir kanıta çevirmeyi.
Kademeli geçiş ve rollback disiplininin, protokol güvenliği kadar kritik bir kontrol olduğunu.

MODÜL 6 — Bulut Network Güvenliği: AWS VPC, Azure VNet/NSG + Hibrit

Kavramsal şema: VPC’te NACL ile alt ağ sınırı, SG ile kaynak bazlı kural; Azure’da subnet başına NSG ve UDR; hibritte DC’den VPN veya ExpressRoute ile hub/TGW ve eşleşen VNet/VPC yolları.

Bulut ağ güvenliği, “veriyi korumak” kadar yanlış bağlantıyı imkânsız kılmak demektir: hangi segment kiminle konuşabilir, hangi çıkış (egress) serbest, bunu hangi kontrol katmanı kanıt ile gösterebilir? Bu modülde AWS VPC ve Azure VNet/NSG yapı taşlarını; ağ mimarisi + kontrol katmanları + görünürlük (flow/log) + misconfiguration yönetimi bakışıyla birleştiriyoruz. On-prem dünyasında birçok kontrol “cihaz üstünde” hissedilirken, bulutta kontrolün büyük kısmı policy-as-config ve denetlenebilir kayıt (auditability) ile yaşar. Bu yüzden hedef; ezber değil, kanıt üreten denetim disiplini kazandırmaktır: kuralı gör → etkisini anla → sinyalini bul → düzeltmeyi küçük kapsamla yap → geri dönüşü hazır tut. Hibrit bağlantılar (VPN/özel hat) resmi büyütür: rota/DNS/policy uyumu bozulursa ya kesinti ya da “fazla erişim” doğar. Tüm içerik yalnızca izinli ortam varsayımıyla ilerler; geniş tarama/istismar yok, sadece denetim–doğrulama–kanıt vardır.

Bu Dersin Hedefleri

Bulutta ağ yapı taşlarını (VPC/VNet, subnet, route, gateway, SG/NSG/NACL) güvenlik etkisiyle yorumlamak.
Güvenlik kontrol katmanlarını (kimlik, segmentasyon, egress, merkezi politika, görünürlük) katman katman konumlandırmak.
East-west (iç ağ) risklerini ve yaygın misconfiguration sınıflarını sinyal/kanıt odaklı tanımak.
Hibrit bağlantılarda rota–DNS–policy uyumunu doğrulamak; drift’i kanıtla yakalamak.
Bulut log/flow kaynaklarını korele ederek görünürlük kurmak ve “ne oldu, nereden biliyorum?” standardına taşımak.
Zorunlu çıktı olarak Misconfiguration Matrisi üretmek (risk → sinyal → kanıt → kontrol → düzeltme → rollback).

6.1 Bulutta ağ yapı taşları

Bulutta ağ; kablo/switch yerine tanımlı bileşenler üzerinden kurulur. AWS’de VPC, Azure’da VNet; CIDR, subnet, route, gateway (internet/özel), peering/transit ve SG/NSG/NACL ile çalışır. “Public subnet” tek ayar değildir — route + public IP + gateway + kural seti birlikte tanımlar.

Çekirdek taşlar

VPC/VNet → subnet → route table → gateway → SG/NSG/NACL → egress zinciri; her katman güvenlik sınırı ve kanıt noktasıdır.

Etiketleme

Ortam, uygulama, owner, veri sınıfı etiketleri; flow ve değişiklik korelasyonunu hızlandırır.

Etki / risk

Risk paterni	Sonuç
Envanter boşluğu	“Kaynak nerede?” yanıtsız; segmentler arası gereksiz erişim.
Geniş egress fark edilmez	Veri sızıntısı yüzeyi büyür.
Route drift	Erişim anında değişir veya kesilir; kayıtsız değişiklikte kronik sapma.

Tespit sinyali / kanıt

Konfig: VPC/VNet, subnet, route, IGW/NAT, SG/NSG/NACL (JSON/CSV).
Control plane: kim, neyi, ne zaman değiştirdi?
Data plane: flow log’da beklenmeyen src/dst/port yönelimi.

Savunma / düzeltme

Önce envanter: VPC/VNet → subnet → route → SG/NSG/NACL → egress.
Public tanımı yazılı olsun: route + IP + gateway + policy (kurum standardı).
Kademeli değişiklik: her adımda önce/sonra kanıt seti.

Örnek: AWS CLI — VPC envanteri (okuma, uydurma çıktı)

bash — aws cli (örnek)

analist@audit:~/evidence$ aws ec2 describe-vpcs --output json | head -n 20 { "Vpcs": [ { "VpcId": "vpc-0a1b2c3d4e5f67890", "CidrBlock": "10.0.0.0/16", "Tags": [{"Key": "Name", "Value": "prod-us-east"}] } ] } # İzinli hesapta; tam çıktı evidence/aws_vpcs.json ile dosyalanır.

6.2 Güvenlik kontrol katmanları

Bulut ağ güvenliğinde tek kontrol her şeyi çözmez; katmanlar birlikte değerlendirilir. AWS’de Security Group ile NACL ayrımı (stateful/stateless, allow/deny) politika tasarımını doğrudan etkiler.

Katman özeti

#	Katman	Soru
1	Kimlik / yetki	Kim hangi ağ kaynağını veya kuralı değiştirebilir?
2	Segmentasyon	Hangi subnet/zone kiminle konuşur?
3	Kural setleri	SG/NSG (çoğunlukla stateful) + NACL (çoğunlukla stateless) uyumu
4	Egress	NAT/proxy/firewall/allowlist; kritik segmentte explicit allow disiplini
5	Merkezi politika	Golden rule, şablon, drift ölçümü
6	Görünürlük	Flow/log/alert, saklama, korelasyon

Etki / risk

Tek katmana güven: ör. yalnız SG/NSG — kimlik ve policy drift riski artar.
Egress boşluğu: veri çıkışı “normal trafik” içinde kaybolur.
Merkezi politika yok: ekip başına farklı standart; denetim maliyeti yükselir.

Tespit sinyali / kanıt

IAM/RBAC ve rol değişiklikleri (control plane).
SG/NSG/NACL ve route değişimleri.
Flow’da dış hedef çeşitliliği (egress drift); NSG/firewall’da beklenmedik allow ve öncelik çakışması.

Savunma / düzeltme

Golden policy: olması gerekeni şablonla; sapmayı ölç.
Egress: varsayılan geniş açık bırakma; gerekiyorsa gerekçe + süre.
Kanıt bağla: kural var mı + tekil doğrulama + log/flow ile karar görünüyor mu?

Kanıt boşluğu uyarısı

“Kural yazdım” ≠ “kontrol çalışıyor”. Allow/deny kararı log veya flow’da görünmüyorsa kontrol kalitesi düşüktür; görünürlük veya log politikasını düzelt.

6.3 East-west riskleri ve misconfiguration

East-west trafik, aynı bulut ağı içi yatay iletişimdir. Sorun çoğu zaman internet değil, içte fazla serbestliktir. Misconfiguration burada yalnızca “bug” değil; varsayılan + acele değişiklik + eksik görünürlük birleşimidir.

Yayılım riski

Aşırı izinli iç kurallar olayın segmentler arası sıçramasını kolaylaştırır.

Hibrit etkisi

Overlapping CIDR veya yanlış route; asimetri, kesinti veya yanlış hedef.

Etki / risk

Risk	Açıklama
Geniş iç izin	Yatay yayılım; bir segmentteki hata diğerine taşınır.
Geçici istisna kalıcılığı	Risk borcu birikir.
Öncelik / gölgeleme	Beklenen deny çalışmıyor gibi görünür.

Tespit sinyali / kanıt

Flow’da segmentler arası beklenmedik port/hedef artışı.
Geniş CIDR’lı kural değişimi; shadow/priority çakışması.
Tekil servis doğrulaması + aynı pencerede log/flow’da karar satırı.

Savunma / düzeltme

Dar kural, net kanıt: servis/port/kaynak bazlı daralt.
Kritik zone’larda flow standardı.
İstisna: owner + gerekçe + expiry + rollback tetikleyicisi.

Karşı kanıt disiplini: “Erişim yok” için DNS mi, route mu, NSG/SG mi? Her hipotez için hem doğrulayan hem çürüten kanıt planla.

6.4 Hibrit bağlantılar

Hibrit; on-prem ile bulutun VPN veya özel hat üzerinden bağlanmasıdır. Üçü birlikte doğru olmalıdır: rota, DNS, policy/segmentasyon. Hata ya kesinti ya da fazla erişim üretir.

Bileşen	Ne doğrulanır?
Rota	Hangi prefix nereye gider? Effective route tutarlı mı?
DNS	İsim çözümü doğru resolver zincirinde mi? (split DNS)
Policy	Hibritten gelen trafik hangi kaynaklara ulaşabilir?

Örnek: Linux — rota ve DNS (hibrit uç doğrulama)

bash — rota + resolver (örnek)

analist@jump:~/evidence$ ip route get 198.51.100.10 198.51.100.10 via 10.50.0.1 dev tun0 src 10.50.0.12 uid 1000 analist@jump:~/evidence$ resolvectl query app.example.org 2>/dev/null || getent hosts app.example.org app.example.org: 198.51.100.10 # Çıktılar notes/ hipotezi (route vs DNS) ile eşlenir.

Etki / risk

Route leak / yanlış propagasyon: beklenmedik görünürlük.
Split-DNS bozulması: aynı isim farklı IP; müdahale zorlaşır.
Asimetrik routing: yarım bağlantı; stateful kontrol sürprizleri.
CIDR çakışması: yanlış segment veya kalıcı çakışma.

Tespit sinyali / kanıt

Gateway/VPN/BGP özet çıktıları; route table / effective route.
DNS resolver davranışı; flow’da on-prem ↔ bulut CIDR konuşması.

Savunma / düzeltme

Minimal prefix ilanı.
DNS kuralı net: iç FQDN → iç resolver; dış → kontrollü çıkış.
Kademeli değişiklik: pilot → genişleme; her adımda kanıt.

6.5 Bulut logları (görünürlük)

Görünürlük iki düzlemdedir: control plane (kim neyi değiştirdi?) ve data plane (trafik gerçekte nasıl aktı?). AWS VPC Flow Logs ve Azure NSG akış kayıtları ürün dokümantasyonunda alan setleri ve gecikme (gerçek zamanlı olmayan yayın) ile tanımlanır; platforma göre özellik evrimi (ör. NSG flow logs geçişi) takip edilmelidir.

Control plane

Kural, route, gateway, NSG/SG değişiklikleri; drift ve değişiklik korelasyonu.

Data plane

Flow, firewall/NSG karar logları; allow/deny ve trafik meta verisi.

Etki / risk

Risk	Sonuç
Log yok	Olay hissedilir; kanıtlanamaz; yanlış müdahale.
Saklama/etiket yok	Olay sonrası korelasyon zayıflar.
Amaçsız çok log	Gürültü; SOC yorulur, sinyal kaybolur.

Tespit — tipik alanlar

Flow: src/dst, port, protokol, aksiyon, byte/packet, zaman penceresi.
NSG/Firewall: kural/priority, karar, yön, hedef.
Değişiklik: kural/route/gateway attach-detach.

Savunma — öncelikli sinyaller (örnek)

İnternet egress drift (dış hedef çeşitliliği artışı).
Beklenmeyen inbound allow.
Route/gateway değişimi.
Log boşluğu (kapalı veya eksik).

Flow log okuma (kısa akış)

Adım	Eylem
1	Zaman penceresini daralt (dakika).
2	src/dst/port sabitle.
3	allow/deny ve ilgili kuralı (NSG/FW/SG/NACL) bul.
4	Aynı pencerede control-plane değişiklik var mı?
5	Karşı kanıt: trafik gelmedi mi, geldi ama deny mı?

Örnek: VPC Flow Log satırı (kavramsal alanlar, uydurma)

bash — flow kesiti (örnek)

analist@audit:~/evidence$ grep "198.51.100.10" ./flow_slice.txt | head -n 3 2 123456789012 eni-0abc123 10.1.2.3 198.51.100.10 443 443 6 12 8400 1520012345 1520012400 ACCEPT OK 2 123456789012 eni-0abc123 203.0.113.50 10.1.2.3 22 22 6 4 240 1520012450 1520012460 ACCEPT OK # Alan sırası platform dokümantasyonuna göre değişir; src/dst/port/aksiyon ve zaman penceresi korelasyonu esastır.

Gecikme notu: Flow log gerçek zamanlı değildir; “şimdi denedim, log’da yok” tek başına yeterli değildir. Aynı pencereye tekil PCAP (kısıtlı hedef/port) veya değişiklik kaydı eklemek kanıtı güçlendirir.

6.6 Misconfiguration matrisi (zorunlu)

Misconfiguration matrisi basit hata listesi değildir; denetim ve olay müdahalesini aynı dilde birleştirir. Sütun zinciri: Misconfig → Etki → Sinyal → Kanıt kaynağı → Kontrol → Düzeltme → Rollback.

Her satır için	Tanım
Fark ediş	Hangi log/flow sinyali bu sınıfı gösterir?
Kanıt	Hangi çıktı dosyası veya kesit?
Düzeltme	Küçük kapsamlı, sahipli aksiyon.
Geri dönüş	Hangi metrik bozulursa rollback?

Etki / risk

Matris yoksa tekrarlayan “tekil vaka” döngüsü.
Öncelik yoksa gürültülü olaylar öne çıkar; en riskli boşluk kalır.
Rollback tanımı yoksa düzeltme kesintiyi büyütür.

Kanıt standardı

Anlatı değil; sistematik konfig + log + flow kesiti.
Her satırda tekil doğrulama testi ve geri dönüş tetikleyicisi.

Savunma — her misconfig sınıfı için

Segmentasyon / egress daraltma.
Flow/log zorunluluğu (kritik segmentlerde).
İstisnalarda owner + expiry.

6.7 HOW-TO: Bulut Misconfig Matrisi Üretimi

Bu runbook, kuruma özel yaşayan bir Misconfiguration Matrisi ve eşlik eden kanıt paketini üretir.

1. Hazırlık

Öğe	İçerik
Kapsam	Ortam (prod/stage), VPC/VNet listesi, hibrit var/yok.
Standart kriterler	Public subnet tanımı; egress prensibi (explicit allow / allowlist / proxy); flow/log zorunlu segmentler; hibrit prefix (minimal ilan, çakışma yok).
Kanıt dizini	`YYYYMMDD_mod6_cloud_misconfig/evidence/`, `notes/`, `manifest.sha256`

2. Uygulama — matrisi doldur

Envanter (kanıtlı): VPC/VNet, subnet, route, gateway, SG/NSG/NACL, flow/log ayarları.
Aday sınıflar: inbound geniş izin; kritik segmentte açık egress; route/gateway hatası; log boşluğu; hibrit rota/DNS uyumsuzluğu; east-west aşırı serbestlik.
Her satır için sütunlar: misconfig sınıfı; etki/risk; beklenen sinyal; kanıt kaynağı; savunma kontrolü; düzeltme; rollback kriteri.

3. Doğrulama (güvenli, tekil)

Tek hedef / tek servis ile “bu kural bu servisi gerçekten etkiliyor mu?”
Allow/deny kararının log/flow’da görünmesi.
Karşı kanıt: erişim yoksa DNS, route, NSG/SG hipotezleri için çürütücü kanıtı önceden yaz.

4. Kanıt paketleme

CLI çıktıları + notes/; gerekirse dar PCAP (tek hedef/port).
manifest.sha256; notlarda en riskli satırlar + gerekçe + aksiyon özeti.

5. Rollback

Plan türleri: kural daraltma; route değişikliği; log açma/kota/maliyet.
Tetikleyiciler: uygulama hata oranı, bağlantı hataları, tünel stabilitesi, kritik entegrasyon kırılması.

6.8 Komut & Araç Okuryazarlığı (Denetim / Doğrulama / Kanıt)

Komutlar yalnızca izinli ortamda konfig okuma, tekil doğrulama ve kanıt üretimi içindir. Geniş tarama/hedef keşfi yoktur. Örnek IP ve adlar uydurmadır.

Kanıt paketi

evidence/ ham çıktı; notes/ hipotez; manifest.sha256 bütünlük; zaman damgası (UTC önerilir).

Güvenli sınır

Tek hedef / tek port veya tek CLI okuma; düşük yoğunluk.

Örnek terminal oturumları (kavramsal)

Aşağıdaki kutular, bu modüldeki kanıt toplama akışının ekranda nasıl görünebileceğini gösterir; IP ve kaynak adları uydurmadır.

Windows PowerShell

PowerShell — Modül 6 (örnek)

PS C:\audit> New-Item -ItemType Directory -Force .\evidence, .\notes | Out-Null PS C:\audit> Get-Date -Format o | Out-File .\evidence\time.txt PS C:\audit> Test-NetConnection -ComputerName 198.51.100.10 -Port 443 | Tee-Object -FilePath .\evidence\tnc_443.txt TcpTestSucceeded : True PS C:\audit> Resolve-DnsName app.example.org | Out-File .\evidence\dns_app_example_org.txt

Linux (bash)

bash — Modül 6 (örnek)

analist@audit:~/evidence$ mkdir -p evidence notes && date -u +"%Y-%m-%dT%H:%M:%SZ" | tee evidence/time_utc.txt 2026-04-17T14:22:01Z analist@audit:~/evidence$ ip route get 198.51.100.10 | tee evidence/ip_route_get.txt analist@audit:~/evidence$ sha256sum evidence/* | tee manifest.sha256

Bulut CLI (AWS)

bash — aws cli (örnek)

analist@audit:~/evidence$ aws ec2 describe-flow-logs --output json | tee aws_flow_logs.json | head -n 14 { "FlowLogs": [ {"FlowLogId": "fl-0abc123", "ResourceId": "vpc-0a1b2c3d", "FlowLogStatus": "ACTIVE"} ] } # Azure için eşdeğer: az network watcher flow-log list ...

Windows (PowerShell)

Klasör + zaman

New-Item -ItemType Directory -Force .\evidence, .\notes | Out-Null
Get-Date -Format o | Out-File .\evidence\time.txt

Tekil port (hibrit)

Test-NetConnection -ComputerName 198.51.100.10 -Port 443 | Out-File .\evidence\tnc_198_51_100_10_443.txt

True ama uygulama yoksa L7/policy/log korelasyonu.

DNS

Resolve-DnsName app.example.org | Out-File .\evidence\dns_app_example_org.txt

Hash

Get-FileHash .\evidence\* -Algorithm SHA256 | Out-File .\manifest.sha256

Linux (bash)

Zaman + klasör

mkdir -p evidence notes
date -u +"%Y-%m-%dT%H:%M:%SZ" | tee evidence/time_utc.txt

Route

ip route show | tee evidence/ip_route.txt
ip route get 198.51.100.10 | tee evidence/ip_route_get_198_51_100_10.txt

Resolver

resolvectl status 2>/dev/null | tee evidence/resolvectl_status.txt

Tekil HTTPS

curl -vk https://example.org 2>&1 | tee evidence/curl_example_org.txt

Hash

sha256sum evidence/* | tee manifest.sha256

macOS

Komutlar

mkdir -p evidence notes
date -u +"%Y-%m-%dT%H:%M:%SZ" | tee evidence/time_utc.txt

scutil --dns | tee evidence/scutil_dns.txt

netstat -rn | tee evidence/netstat_route.txt
route -n get 198.51.100.10 | tee evidence/route_get_198_51_100_10.txt

shasum -a 256 evidence/* | tee manifest.sha256

Bulut CLI — okuma / denetim

Yalnız yetkili hesapta; çıktıları evidence/ altına kaydedip hash’leyin.

Platform	Örnek komut (özet)	Not
AWS	`aws ec2 describe-vpcs --output json \| tee evidence/aws_vpcs.json`	VPC envanteri; etiket korelasyonu.
AWS	`describe-subnets`, `describe-route-tables`	Public/private route kanıtı.
AWS	`describe-internet-gateways`, `describe-nat-gateways`	Çıkış kapıları.
AWS	`describe-security-groups`, `describe-network-acls`	SG + NACL kapsamı.
AWS	`describe-flow-logs`	Etkinlik ve hedef; gecikme penceresini unutma.
Azure	`az network vnet list -o json`	VNet envanteri.
Azure	`az network nsg list`, `nsg rule list --nsg-name <NSG> --resource-group <RG>`	Öncelik ve geniş aralık sinyali.
Azure	`az network route-table list`	UDR görünümü.

Azure NSG akış logları için platform dokümantasyonunu takip edin; bazı ortamlarda yeni akış/gözlemlenebilirlik yaklaşımına geçiş planı gerekebilir.

tcpdump / Wireshark (tekil doğrulama)

Bulutta TAP her zaman yok; ana görünürlük flow log. Hibrit veya kritik serviste kısa PCAP kanıtı güçlendirir.

tcpdump

sudo tcpdump -nn -i eth0 host 198.51.100.10 and tcp port 443 -c 200 -w evidence/single_test.pcap

sudo tcpdump -nn -i eth0 host 198.51.100.10 and tcp port 443 -G 30 -W 3 -w evidence/single_%Y%m%d%H%M%S.pcap

Gidiş var dönüş yok → asimetri/policy; hiç gidiş yok → route/DNS.
Dar filtre, kısa süre, izinli ortam.

Örnek: tcpdump çıktısı (tekil hedef/port, uydurma)

tcpdump — tekil doğrulama (örnek)

analist@jump:~$ sudo tcpdump -nn -i eth0 host 198.51.100.10 and tcp port 443 -c 4 14:22:01.112233 IP 10.50.0.12.52431 > 198.51.100.10.443: Flags [S], seq 0, win 64240 14:22:01.145901 IP 198.51.100.10.443 > 10.50.0.12.52431: Flags [S.], seq 0, ack 1 14:22:01.146012 IP 10.50.0.12.52431 > 198.51.100.10.443: Flags [.], ack 1 # SYN / SYN-ACK görünür; dönüş yoksa asimetri veya policy şüphesi.

Wireshark — kanıt odaklı

Konu	Ne bakılır?
Display filter	`ip.addr == 198.51.100.10 && tcp.port == 443`
Conversations / Endpoints	Beklenmeyen peer var mı?
Expert / stream	Retransmit, TLS vs HTTP katmanı
Çıktı	CSV/screenshot + PCAP hash → manifest

6.9 HOW-TO (çıktı): Misconfiguration Matrisi (örnek şablon + doldurulmuş örnek)

Aşağıdaki örnek uydurmadır. Çok sütunlu tablo yerine her satır ayrı kartta verilmiştir; aynı alanları kendi matrisinize aktarabilirsiniz.

Inbound

Misconfig: yönetim portu için geniş kaynak

Etki / risk: Yetkisiz erişim yüzeyi büyür.
Beklenen sinyal: Beklenmeyen inbound allow denemeleri.
Kanıt: SG/NSG kural çıktısı + flow/NSG log.
Savunma: Kaynak daraltma; servis bazlı izin.
Düzeltme: Kaynağı daralt; yalnız gerekli port/kimlik.
Rollback: Uygulama erişimi veya VPN akışı bozulursa.

Egress

Misconfig: kritik segmentte geniş egress

Etki / risk: Veri sızıntısı; kontrol dışı dış bağlantılar.
Beklenen sinyal: Dış hedef çeşitliliği artışı.
Kanıt: Flow log + NAT/firewall log.
Savunma: Allowlist/proxy; merkezi egress politikası.
Düzeltme: Egress daralt; kritik hedefleri allowlist.
Rollback: Kritik API çağrıları başarısız olursa.

Route

Misconfig: yanlış gateway veya route bağlama

Etki / risk: Erişim kesintisi veya beklenmeyen internet yolu.
Beklenen sinyal: Route değişimi sonrası trafik patern değişimi.
Kanıt: Route config + flow log + change log.
Savunma: Public subnet kriter standardı.
Düzeltme: Route düzelt; public IP politikasını kontrol et.
Rollback: Hata oranı veya süre belirgin artarsa.

Loglama

Misconfig: flow veya diagnostic log kapalı

Etki / risk: Olay kanıtsız kalır.
Beklenen sinyal: “Kayıt yok” boşluğu.
Kanıt: Log ayar çıktısı.
Savunma: Zorunlu log standardı.
Düzeltme: Logları aç; saklama ve etiket uygula.
Rollback: Maliyet veya limit eşiği aşılırsa.

Hibrit

Misconfig: overlapping CIDR veya route leak

Etki / risk: Kesinti veya beklenmeyen erişim.
Beklenen sinyal: Asimetrik trafik; beklenmeyen hedefler.
Kanıt: Effective route + flow log.
Savunma: Prefix yönetimi; minimal ilan.
Düzeltme: Prefix düzelt; çakışmayı kaldır.
Rollback: Tünel stabilitesi bozulursa.

East-West

Misconfig: içte aşırı serbestlik

Etki / risk: Olay yayılım riski.
Beklenen sinyal: Segmentler arası port veya hedef artışı.
Kanıt: Flow log + kural farkı.
Savunma: Mikro-segmentasyon.
Düzeltme: Servis bazlı daralt; istisnaya süre koy.
Rollback: İç servis çağrıları kırılırsa.

6.10 Operasyonel Senaryo

Senaryo: Hibrit erişim kararsızlığı + unutulan yönetim kapısı — route/NSG drift ve geniş kural ayrıştırması.

Belirti

On-prem (uydurma 203.0.113.0/24) üzerinden bulut uygulamasına (198.51.100.10:443) erişim bazen çalışıyor bazen çalışmıyor. Flow/NSG loglarında 443’e ek olarak :22 için az sayıda ACCEPT var; kaynaklar kurum VPN bloğu ile uyumlu değil.

Örnek: aynı pencerede DNS + tekil port testi (PowerShell)

PowerShell — senaryo 6.10 (örnek)

PS C:\evidence> Get-Date -Format o | Tee-Object .\evidence\window_start.txt 2026-04-17T15:03:12.4412345+03:00 PS C:\evidence> Resolve-DnsName app.example.org Name: app.example.org Type: A TTL: 300 Address: 198.51.100.10 PS C:\evidence> Test-NetConnection -ComputerName 198.51.100.10 -Port 443 TcpTestSucceeded : True # Aynı dakikada flow/NSG kesiti ile eşlenir; DNS değişimi hipotez 3’ü güçlendirir.

Örnek: NSG kural listesinde 22 (Azure CLI, uydurma)

bash — az cli (örnek)

analist@audit:~/evidence$ az network nsg rule list --nsg-name app-nsg --resource-group rg-prod -o table 2>/dev/null | head -n 8 Name Priority Access Protocol SourcePort DestPort SourceAddress Destination ssh-mgmt 120 Allow Tcp * 22 0.0.0.0/0 * https-app 110 Allow Tcp * 443 203.0.113.0/24 * # Geniş 22 kaynağı kural çıktısı ile çapraz doğrulanır (6.11).

Hipotezler (önceliklendir)

#	Hipotez
1	Hibrit route drift / asimetrik routing (yanlış next-hop).
2	NSG/SG öncelik veya çakışma drift (443 kararları değişiyor).
3	Split DNS: `app.example.org` zamanla farklı IP.
4	Unutulan geniş yönetim kuralı (22 için geniş kaynak).
5	Karşı hipotez: sorun ağ değil, uygulama (5xx vb.).

Minimum kanıt seti

Taraf	Ne toplanır?
İstemci (on-prem)	Aynı pencerede DNS; route/effective route; tekil 443 testi; zaman damgası.
Bulut	Route/effective route; SG/NSG JSON; flow/NSG kesiti; control-plane değişiklik; `manifest.sha256`.

Analiz adımları (kanıtla ayrıştırma)

Adım	Eylem
1	DNS: Aynı isim aynı pencerede aynı IP’ye mi? Değişiyorsa DNS hipotezini güçlendir; değişmiyorsa zayıflat.
2	Route: Hedef için next-hop beklenen mi?
3	443 tekil test + korelasyon: Aynı dakikada test; flow/NSG’de allow/deny satırı.
4	22 (SSH) ayrı incele: Kural çıktısında geniş kaynak var mı? ACCEPT’ler yetkili kaynak mı? (Bkz. 6.11.)
5	Uygulama karşı kanıtı: Ağ “443 stabil” diyorsa uygulama logunda 5xx artışı var mı?

Karar özeti

Route drift: minimal prefix; pilot; standarda çek.
443 çakışması: öncelik net; servis bazlı daralt; log zorunlu.
22 geniş kural: derhal daralt; owner + expiry.

Rapor (Bulgu → Etki → Öneri → Kanıt)

Bulgu (örnek): 443’ün bazı denemelerde ulaşmaması (route ile uyumlu); 22 için beklenmeyen kaynaklardan ACCEPT; SG/NSG’de yönetim için geniş aralık. Etki: hibrit kararsızlık; geniş yönetim kuralı yüzey büyütür. Öneri: prefix minimal; 443 dar ve öncelikli; 22 yalnız yetkili kaynak; flow/log standardı. Kanıt: DNS + route + SG/NSG JSON + flow kesiti + zaman + manifest.

6.11 Port 22 (SSH) ACCEPT — karşı kanıt kontrolü

Flow’da TCP/22 ACCEPT görüldüğünde bunu tek başına yorumlamayın; kural çıktısı ve kaynak aralığı ile çapraz doğrulama yapın.

Soru	Karşı kanıt / kanıt
Kural gerçekten geniş mi?	SG/NSG JSON’da kaynak CIDR ve priority; beklenen “jump box” aralığı mı?
ACCEPT kayıtları kimden?	VPN/bastion bloğu ile eşleşiyor mu; yoksa beklenmeyen coğrafya veya aralık mı?
Ağ mı uygulama mı?	443 kanıtı stabil ise 5xx veya app log ile uygulama hipotezini ayır.

Geniş 22 kuralı kanıtlanırsa: hemen daralt (yalnız yetkili kaynak), istisna için owner + expiry.
Raporu 6.10 senaryosu ile birlikte okuyun; tekrarlayan bulguları misconfiguration matrisine satır olarak ekleyin.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

VPC / VNet Bulutta sanal ağ; adres alanı ve segmentleri tanımlar.

Subnet VPC/VNet içindeki alt ağ; segmentasyonun temel birimi.

Route Table Trafiğin nereye gideceğini belirleyen yönlendirme kuralları.

IGW / NAT Gateway İnternet çıkışı ve kontrollü çıkış kapıları (kavramsal).

Security Group / NSG Kaynak düzeyinde giriş/çıkış kuralları; (çoğunlukla) stateful politika katmanı.

NACL Subnet seviyesinde erişim kontrol listesi; çoğunlukla stateless allow/deny mantığı.

East-west trafik Aynı bulut ağı içindeki servisler arası yatay trafik.

Egress Dışarı çıkış trafiği; veri sızıntısı riskinin kritik yüzeyi.

Control plane log Konfigürasyon/değişiklik kayıtları (kim neyi değiştirdi?).

Flow log Trafiğin alanlarını/meta verisini kaydeden akış kayıtları; gerçek zamanlı değildir.

Misconfiguration matrisi Hata sınıfı → etki → sinyal → kanıt → kontrol → düzeltme → rollback haritası.

Asimetrik routing Gidiş-dönüş yollarının farklı olması; stateful kontrolleri bozabilir.

Split DNS İç/dış isimlerin farklı resolver kurallarıyla çözülmesi yaklaşımı.

Kendini Değerlendir

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

Bir subnet’in “public” sayılmasını en doğru şekilde belirleyen yaklaşım hangisidir?

A) Subnet adı “public” ise public’tir

B) Subnet’te çalışan VM sayısı fazlaysa public’tir

C) Route tablosu + internet gateway yönlendirmesi + public IP/atama politikası + kural seti birlikte değerlendirilir

D) Yalnız SG/NSG üzerinde 0.0.0.0/0 allow varsa public’tir

E) NAT Gateway bağlıysa public’tir

Doğru: C
Gerekçe: Public/private tek bir ayar değildir; route+gateway+IP/policy birleşimi belirler. D tek başına yanıltıcı; E tersine “private çıkış” için sık kullanılır.

“Kural var ama kontrol çalışıyor mu?” sorusuna en güçlü cevap hangi kanıt kombinasyonuyla üretilir?

A) Yalnız kural ekran görüntüsü

B) Yalnız flow log (tek satır)

C) Tekil doğrulama testi + aynı pencere flow/NSG log kararı + ilgili kural konfig çıktısı

D) Yalnız kullanıcı beyanı (“dün çalışıyordu”)

E) Yalnız ping sonucu

Doğru: C
Gerekçe: Konfig + davranış + zaman eşleştirme birlikte denetlenebilir kanıt üretir. Diğerleri tek boyutludur.

AWS’de Security Group ile NACL arasındaki doğru fark seti hangisidir?

A) SG stateless, NACL stateful; ikisi de deny yazamaz

B) SG stateful; NACL stateless; NACL allow/deny kuralı içerebilir

C) SG yalnız subnet’e uygulanır; NACL yalnız instance’a uygulanır

D) SG yalnız inbound’u kontrol eder; NACL yalnız outbound’u kontrol eder

E) SG log üretemez; NACL her zaman payload kaydeder

Doğru: B
Gerekçe: SG/NACL karşılaştırması stateful/stateless ve allow/deny mantığıyla ayrışır. C/D/E yanlış genellemelerdir.

Hibrit erişim “bazen var bazen yok” belirtisinde DNS hipotezini en hızlı güçlendiren kanıt hangisidir?

A) Tek seferlik curl çıktısı

B) Aynı dakika içinde tekrarlı DNS çözümleme kayıtlarında farklı IP dönüşleri

C) SG kural listesi

D) Flow loglarda 443 ACCEPT görülmesi

E) Subnet sayısının artması

Doğru: B
Gerekçe: Split DNS doğrudan isim→IP dalgalanmasıyla yakalanır. D DNS’i doğrulamaz; C/D başka hipotezlere gider.

“Egress drift” için en anlamlı erken uyarı sinyali hangisidir?

A) İnternal east-west trafiğin tamamen sıfırlanması

B) Flow loglarda kısa sürede dış hedef (dst) çeşitliliğinin belirgin artması

C) VPN tünelinin up olması

D) Route table sayısının azalması

E) SG’de inbound kuralların artması

Doğru: B
Gerekçe: Egress drift çoğunlukla yeni/çok sayıda dış hedefe çıkışla görünür. Diğerleri dolaylı/ilgisiz.

Misconfiguration matrisinde “Rollback Kriteri” sütununun asıl amacı nedir?

A) Daha uzun rapor yazmak

B) Düzeltme sonrası başarıyı yalnız hislerle ölçmek

C) Düzeltmenin iş etkisini ölçüp, eşik aşılırsa kontrollü geri dönüş tetiklemek

D) Log saklama maliyetini artırmak

E) Tüm değişiklikleri geri almak

Doğru: C
Gerekçe: Rollback, kesinti riskini yönetmek için ölçülebilir tetikleyiciler ister. E “her zaman geri al” değildir.

Flow loglarda “kayıt yok” durumu görüldüğünde en doğru yorum hangisidir?

A) Trafik kesinlikle geçmemiştir

B) Trafik kesinlikle engellenmiştir

C) Flow loglar gerçek zamanlı değildir; ayrıca log etkinliği/apsama/saklama boşluğu olabilir; karşı kanıt gerekir

D) Uygulama katmanı kesin sorunludur

E) DNS kesin hatalıdır

Doğru: C
Gerekçe: Flow loglar gerçek zamanlı değildir ve kapsama/log ayarı boşluğu olabilir. A/B aşırı kesin.

İnceleme sırasında “22 için az sayıda ACCEPT” görülüyor. En güvenli doğrulama yaklaşımı hangisidir?

A) Rastgele çok sayıda IP/port denemesi yaparak “nereler açık?” keşfetmek

B) Konfig çıktısında ilgili kuralı bulmak + ACCEPT satırlarını zaman/kimlik ile eşleştirmek + sadece yetkili kaynaktan tekil doğrulama yapmak

C) Logları kapatmak (gürültü azaltmak)

D) Tüm subnet’leri public yapmak (test kolaylaşsın)

E) Kuralı değiştirmeden “zaten az” diyerek geçmek

Doğru: B
Gerekçe: Denetim kanıtı + korelasyon + tekil doğrulama, white-hat ve düşük riskli yöntemdir. A suistimale açık ve kapsam dışıdır.

East-west riskleri neden sıklıkla “internet riskinden” daha kritik hale gelir?

A) Çünkü bulutta internet hiç yoktur

B) Çünkü içteki aşırı izin, bir olayın segmentler arasında hızlı yayılmasına yol açabilir

C) Çünkü flow loglar yalnız east-west’i gösterir

D) Çünkü SG/NSG east-west’i asla kontrol etmez

E) Çünkü hibrit bağlantılar east-west’i engeller

Doğru: B
Gerekçe: İçteki serbestlik olay yayılımını büyütür. C/D/E yanlış genelleme; A yanlış.

Azure tarafında NSG flow logs görünürlüğü planlanırken en doğru yaklaşım hangisidir?

A) Platform notlarını yok sayıp, uzun vadeli plan yapmamak

B) Log formatını payload kaydı sanmak

C) Güncel dokümantasyondaki yaşam döngüsü notlarını dikkate alıp, uygun flow logging yaklaşımına geçiş planlamak

D) Tüm logları sonsuz süre saklamak

E) Logları yalnız olay olunca açmak

Doğru: C
Gerekçe: Görünürlük kontrolleri “yaşam döngüsü” ve platform yönlendirmeleriyle uyumlu olmalı. D maliyet/risk; E kanıt boşluğu doğurur.

Kapanış: Bu modülde neler öğrendik?

Bulut ağ yapı taşlarının (VPC/VNet, subnet, route, gateway) doğrudan güvenlik sınırı oluşturduğunu; “public/private” gibi kavramların çoklu bileşenle belirlendiğini.
Güvenliğin tek katmanla değil; kimlik → segmentasyon → kural seti → egress → merkezi politika → görünürlük zinciriyle kurulduğunu.
East-west risklerinin çoğu zaman kritik olduğunu; misconfiguration’ın varsayılanlar ve drift ile büyüdüğünü; istisnaların owner+expiry ile yönetilmesi gerektiğini.
Hibrit bağlantılarda rota + DNS + policy uyumu bozulursa kesinti veya fazla erişimin doğabileceğini ve bunu kanıtla ayrıştırma yöntemini.
Flow/log ve kontrol-plane kayıtlarını birlikte okuyarak “ne oldu?” sorusunu denetlenebilir hale getirmeyi; flow logların gerçek zamanlı olmadığını.
Kurumsal denetim ritmi için misconfiguration matrisinin nasıl üretileceğini; her satıra doğrulama ve rollback bağlamayı.

MODÜL 7 — SDN ve Modern Ağ Mimarileri

Kavramsal şema: kuzeyde API ile otomasyon; SDN kontrol düzleminde politika ve akış kararı; güneyde protokollerle veri düzlemine programlama; altta leaf–spine ile yüksek hızlı iletim ve soyut servis zinciri.

Bu modül, “ağı cihaz cihaz yönetmek” yerine “politikayı merkezden tanımlayıp tüm ağa tutarlı uygulatma” fikrinin güvenlik etkisini ele alır. SDN’de (Software-Defined Networking) kontrol düzlemi (control plane) ile veri düzlemi (data plane) ayrıldıkça, tutarlılık ve otomasyon kazanımları artar; fakat yanlış bir politika güncellemesinin hızla tüm ortama yayılması gibi “tek hatanın büyük etki” riskleri de büyür. Bu yüzden odak, ürün/vendör ezberi değil; politika yaşam döngüsü, değişiklik yönetimi, policy drift (beklenen politikadan sapma) ve kanıt üretimi disiplinidir. Modern yaklaşımlarda “niyet (intent) → politika → doğrulama” döngüsünün neden kritik olduğu; görünürlük, izlenebilirlik ve geri dönüş (rollback) mantığıyla birlikte ele alınır. Modül boyunca yaklaşım savunma odaklıdır: yalnızca denetim/okuma, güvenli doğrulama ve kanıt paketleme; geniş kapsamlı tarama/istismar/bypass “nasıl yapılır” yoktur.

Bu Dersin Hedefleri

SDN’de control plane ve data plane ayrımını güvenlik ve operasyon etkisiyle açıklayabileceksin.
Merkezi politika yönetiminin avantajlarını ve “hatalı değişikliğin hızla yayılması” riskini yönetim disipliniyle değerlendirebileceksin.
Policy drift kavramını, tipik kaynaklarını ve tespit yaklaşımını (snapshot + diff + audit log + doğrulama) tanımlayabileceksin.
SDN ekosistemini ürün adından bağımsız “kavramsal bileşenler” üzerinden okuyabileceksin (controller, policy store, enforcement noktaları, API’ler, telemetry/log).
Intent-based yaklaşımda AI/ML önerilerinin “kanıt değil hipotez” olduğunu; guardrail + insan onayı + doğrulama kapısının neden şart olduğunu temellendirebileceksin.
Golden Policy yaklaşımıyla drift tespiti için uygulanabilir bir runbook/checklist üretebilecek ve “Bulgu → Etki → Öneri → Kanıt (rapor formatı)” ile raporlayabileceksin.

7.1 Control plane vs data plane

SDN’de güvenliğin özü, karar katmanı ile taşıma katmanını birlikte okumaktır: control plane niyeti ve politikayı üretir; data plane bu kararı trafikte uygular.

Control plane (karar)

Politika/rota/akış hesaplar, sürüm yönetir, enforcement noktalarına dağıtır.

Data plane (uygulama)

Akışı iletir/engeller; paket kararını gerçek trafiğe dönüştürür.

Etki / risk matrisi

Boyut	Kazanım	Risk
Merkezileşme	Tutarlı politika	Tek hatanın hızlı yayılımı
Otomasyon	Daha hızlı değişiklik	Yanlış şablonla kitlesel drift
Görünürlük	Audit + telemetry korelasyonu	Eksik logda yanlış teşhis

Tespit sinyali / kanıt

Control plane: policy publish, role değişimi, API token kullanımı, sıra dışı çağrı hacmi.
Data plane: beklenmeyen allow/deny, flow davranış sıçraması, policy version uyumsuzluğu.
Doğrulayıcı kombinasyon: aynı dakika içinde audit log + enforcement log + tekil servis testi.
Karşı kanıt: aynı pencerede DNS/TLS/routing sorunu baskınsa drift hipotezi zayıflar.

Savunma / düzeltme

Controller erişiminde least privilege + MFA/SSO + yönetim ağı izolasyonu.
Değişikliklerde zorunlu kayıt, gözden geçirme, rollback kriteri.
“Kim değiştirdi?” sorusu için audit kapsamı ve kimlik bağlamı tam olmalı.

Dikkat: HA mimari olsa bile controller güvenlikte kritik varlıktır; yanlış kararın etki alanı büyüktür.

7.2 Policy drift ve değişiklik yönetimi riskleri

Policy drift, golden baseline ile sahadaki mevcut politika arasındaki sapmadır. Hedef yalnızca “fark bulmak” değil; farkın etkisini sınıflandırıp güvenli düzeltme yapmaktır.

Drift kaynakları (en sık)

Otomasyon hatası

Yanlış şablon/parametre ile kitlesel kural farkı.

Kayıtsız acil değişiklik

Uygulandı ama change kaydına işlenmedi.

Yetki sapması

Gereğinden geniş yazma yetkisi veya service account suistimali.

Etki ve önceliklendirme

Sınıf	Örnek drift	Öncelik
Over-permission	Yönetim erişimi veya segmentler arası geniş allow	Kritik
Over-restriction	Kritik servis akışının deny olması	Kritik/Orta
Operasyonel drift	Log kapatılması, kural sırası bozulması	Orta
Dokümantasyon drift	Etiket/açıklama farklılığı	Düşük

Tespit sinyali / kanıt

Golden vs current diff (eklenen/çıkarılan/değişen kural).
Ticket/CR ile sahadaki değişiklik eşleşmesi.
Policy version ile enforcement version uyumu.
Drift başlangıcı ve outage başlangıcı zaman korelasyonu.

Savunma / düzeltme

Golden Policy versiyonlu ve değişmez referans olmalı.
Rollback kriteri önceden tanımlı olmalı; kritik akış bozulursa anında geri dönüş.
Güvenlik + NetOps + Platform ortak değişiklik dili kullanmalı.

7.3 SDN örnek ekosistem (kavramsal)

SDN’i ürün adıyla değil, bileşen akışıyla okumak daha etkilidir: politika nerede üretilir, nerede saklanır, nerede uygulanır, nerede kanıtlanır?

Bileşen	Görev	Kritik risk
Controller / Orchestrator	Politika üretimi ve dağıtımı	Yanlış publish ile yaygın etki
Policy Store	Onaylı politika sürümleri	Birden fazla “doğru kaynak” oluşması
Enforcement points	Kuralın sahada uygulanması	Sürüm uyumsuzluğu
Northbound API	Otomasyon ve üst sistem entegrasyonu	Yanlış script ile kitlesel drift
Southbound katman	Controller→cihaz dağıtım yolu	Kimlik/şifreleme zayıflığı

Sinyal ve kanıt

API çağrı hacmi, service account kullanımı ve token davranışı.
Controller telemetry’de ani rollout dalgaları.
Enforcement üzerinde beklenmeyen policy version sıçraması.

Savunma yaklaşımı

Read-only ve write rollerini net ayır; yazma yetkisini minimuma indir.
Pipeline’da “önce doğrulama → dağıtım → dağıtım sonrası doğrulama” kapısı zorunlu olsun.
Policy store için versiyonlama + immutable kayıt + audit izlenebilirliği uygula.

Not: RESTCONF için HTTPS (tipik 443), NETCONF over SSH için tipik 830 portu farkındalığı operasyonel teşhiste önemlidir.

7.4 AI/ML ile intent-based ağ yönetimine giriş (kavramsal)

Intent-based yaklaşımda sistem “nasıl yapacağını” değil “ne istediğini” alır. AI/ML burada karar verici değil, öneri motoru olarak ele alınmalıdır.

Kazanç

Daha hızlı geri bildirim, tutarlı politika üretimi, daha düşük manuel hata.

Temel risk

Yanlış önerinin otomatik uygulanmasıyla geniş etkili kesinti.

Tespit sinyali / kanıt

Niyet→politika dönüşümünde kapsam genişlemesi (port/CIDR büyümesi).
Auto-change olaylarının hata penceresiyle zaman çakışması.
Dönüşüm öncesi/sonrası politika diff + tekil test + audit log korelasyonu.

Guardrail çerçevesi

Kontrol	Neden gerekli?
İnsan onayı	Öneri ile karar ayrımını korur
Immutable kısıtlar	Kritik akışların yanlışlıkla silinmesini engeller
Otomatik rollback	Hata oranı artışında etkili geri dönüş sağlar

7.5 HOW-TO: Policy Drift Tespiti (Golden Policy) — kavramsal çerçeve

Bu çerçeve, drift tespitini tekrarlanabilir bir iş akışına dönüştürür: snapshot → normalize → diff → korelasyon → doğrulama → karar.

Aşama	Ne yapılır?	Çıktı
1. Snapshot	Golden ve current state read-only alınır	Kaynak dosyalar
2. Bütünlük	Hash + zaman damgası üretilir	Kanıt izi
3. Normalleştirme	Format gürültüsü azaltılır	Canonical dosyalar
4. Diff	Gerçek kural farkları ayrıştırılır	Drift listesi
5. Korelasyon	Audit ve olay zamanı eşlenir	Kök neden hipotezi
6. Karar	Kritikse rollback, değilse kontrollü düzeltme	Aksiyon planı

Operasyonel farkındalık için iyi bilinen portlar: OpenFlow TCP 6633/6653, NETCONF over SSH tipik 830, RESTCONF tipik HTTPS 443.

7.6 Komut & Araç Okuryazarlığı (Windows / Linux / macOS + Wireshark)

Bu bölümün amacı komut ezberi değil, kanıt zinciri üretimi: snapshot, hash, diff, tekil doğrulama ve korelasyon.

Hızlı komut seti (özet)

Adım	Windows	Linux/macOS
Hash	`Get-FileHash .\golden-policy.json -Algorithm SHA256`	`sha256sum golden-policy.json` / `shasum -a 256 golden-policy.json`
Canonical	`ConvertFrom-Json \| ConvertTo-Json -Depth 99`	`jq -S . file.json > file.canon.json`
Diff	`Compare-Object ... \| Out-File .\policy-diff.txt`	`diff -u golden.canon current.canon > policy-diff.patch`
Tekil test	`Test-NetConnection 203.0.113.30 -Port 443`	`curl -I https://203.0.113.30/`

Örnek terminal oturumları (kavramsal)

PowerShell

PowerShell — drift kanıtı

PS C:\evidence> Get-FileHash .\golden-policy.json -Algorithm SHA256 PS C:\evidence> Get-FileHash .\current-policy.json -Algorithm SHA256 PS C:\evidence> Compare-Object (Get-Content .\golden-policy.canon.json) (Get-Content .\current-policy.canon.json) | Out-File .\policy-diff.txt

Linux/macOS

bash — canonical ve diff

analist@host:~/evidence$ jq -S . golden-policy.json > golden-policy.canon.json analist@host:~/evidence$ jq -S . current-policy.json > current-policy.canon.json analist@host:~/evidence$ diff -u golden-policy.canon.json current-policy.canon.json > policy-diff.patch

Wireshark korelasyon notu

Kısa süreli, ilgili arayüzde, ilgili zaman penceresinde yakala (do not harm).
Display filter: tcp.port == 6653 || tcp.port == 6633 || tcp.port == 830
Conversations ve Expert Information çıktısını audit log zamanıyla eşleştir.

7.7 HOW-TO: Golden Policy ile Policy Drift Tespiti (Runbook / Checklist)

Aşağıdaki runbook, ürün bağımsız bir drift süreci sunar: kısa, tekrar edilebilir ve kanıt odaklı.

Runbook (özet kontrol listesi)

Adım	Ne yapılır?	Başarı ölçütü
1. Hazırlık	Golden source, scope, canonical kuralı ve kanıt dizini netlenir.	Her artefaktın sahibi ve formatı bellidir.
2. Snapshot	Current state read-only alınır; golden ile birlikte hash’lenir.	Dosyalar değişmez, zaman damgası kayıtlıdır.
3. Diff	Canonical dönüşüm sonrası drift çıkarılır ve sınıflandırılır.	Kritik/Orta/Düşük listesi hazırdır.
4. Korelasyon	Audit log, outage zamanı ve policy version eşleştirilir.	Hipotez güçlenir veya elenir.
5. Doğrulama	Tek hedef/tek servis testleri ve karşı kanıt kontrolleri yapılır.	Neden-sonuç bağı doğrulanır.
6. Karar	Kritik driftte rollback; değilse kontrollü düzeltme ve yeniden test.	Etki yönetilir, kesinti büyümez.

Minimum kanıt paketi

Golden hash + current hash
Canonical diff çıktısı
Audit log kesiti (actor, action, version, time)
Tekil doğrulama test çıktısı
Kısa zaman çizelgesi ve karar notu

Dikkat: Audit/log kapsamı eksikse önce görünürlük boşluğunu kapat; otomatik düzeltme refleksiyle ilerleme.

7.8 Operasyonel Senaryo (izinli/uydurma)

Belirti: API katmanı, DB katmanına tcp/443 erişemiyor; sorun planlı değişiklikten ~10 dakika sonra başladı.

Hipotezler

#	Hipotez
1	Segmentasyon politikası aşırı kısıtlandı (over-restriction).
2	Golden ile current arasında policy drift oluştu.
3	Otomasyon pipeline’ı yanlış şablon/parametre yayımladı.
4	Karşı hipotez: sorun DNS/TLS/routing katmanında.

Minimum kanıt seti

Controller audit log (publish, actor, version, change ref).
Data plane deny/flow kesiti.
Golden + current snapshot ve canonical diff.
Tekil servis doğrulama testi (443).

Kanıt kesiti (uydurma)

2026-02-10T14:22:11Z ACTION=POLICY_PUBLISH ACTOR=svc-automation POLICY_SET=prod-segmentation VERSION=42 2026-02-10T14:23:02Z DECISION=DENY SRC=198.51.100.20 DST=203.0.113.30 SVC=tcp/443 REASON=segment_policy_no_match PS C:\evidence> Test-NetConnection 203.0.113.30 -Port 443 TcpTestSucceeded : False

Analiz adımları

Adım	Eylem
1	Zaman korelasyonu: publish → deny → belirti zinciri doğrulanır.
2	Golden/current diff ile API→DB 443 akışının çıkarılıp çıkarılmadığı kontrol edilir.
3	Drift sınıfı belirlenir; kritik akış kesintisi varsa kritik etki.
4	Change ref içeriği ile gerçek fark karşılaştırılır (yanlış şablon olasılığı).
5	Karşı kanıt: DNS/TLS/routing bulguları kontrol edilerek yanlış teşhis engellenir.

Karar ve rapor

Karar: Kritik kesinti + drift doğrulanırsa onaylı sürüme rollback.
Öneri: Pipeline’a akış matrisi doğrulama kapısı ve kritik guardrail eklenir.
Kanıt: Audit + deny + tekil test + hash + diff artefaktları birlikte raporlanır.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

SDN Yazılım Tanımlı Ağ; kontrol mantığının merkezileştiği yaklaşım

Control Plane Karar veren katman (politika/rota/flow kararları)

Data Plane Paketi ileten/engelleyen uygulayıcı katman

Controller Politikayı üreten/dağıtan merkezi bileşen (kavramsal)

Policy Drift Beklenen politika ile sahadaki politikanın sapması

Golden Policy Onaylı “tek doğru kaynak” baseline politika

Northbound API Üst sistemlerin controller ile konuştuğu arayüz

Southbound Arayüz Controller’ın sahadaki cihaz/enforcement noktalarıyla konuştuğu katman

RESTCONF HTTP tabanlı yapılandırma/ durum erişim yaklaşımı (genellikle HTTPS üzerinden)

NETCONF Yapılandırma protokolü; SSH üzerinden varsayılan port 830 kullanımıyla anılır

OpenFlow SDN’de akış/iletişim yaklaşımı; iyi bilinen TCP portları 6633/6653

Intent-Based Niyet tabanlı: “ne istiyorum” → politika → doğrulama döngüsü

Telemetry Sistem davranışını ölçen metrik/log/veri akışı

Rollback Hatalı değişikliği geri alma / önceki sürüme dönüş

Kendini Değerlendir

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

Bir kurumda SDN kontrolcüsünde değişiklik sonrası geniş çaplı erişim sorunları başladı. Aşağıdakilerden hangisi “drift hipotezini” en güçlü şekilde doğrulayan kanıt kombinasyonudur?

A) Kullanıcı şikâyetleri + ping gecikmesi artışı

B) Controller audit log’da policy publish + enforcement deny kaydı + tekil servis doğrulama testi (başarısız)

C) Wireshark’ta artan TLS trafiği + CPU artışı

D) DNS sunucusunda cache temizlenince düzelmesi

E) Route table’da default gateway varlığı

Doğru: B
Gerekçe: B, değişiklik (audit), sonuç (deny) ve etkiyi (tekil doğrulama) aynı zaman penceresinde bağlar. A/C tek başına korelasyon; D/E alternatif kök nedenlere işaret eder.

Policy drift tespitinde “normalleştirme (canonical format)” neden kritiktir?

A) Çünkü drift’i otomatik olarak düzeltir

B) Çünkü diff çıktısındaki format gürültüsünü azaltarak gerçek kural değişimini görünür kılar

C) Çünkü controller loglarını otomatik üretir

D) Çünkü TLS sertifikasını doğrular

E) Çünkü data plane’in çalışmasını hızlandırır

Doğru: B
Gerekçe: Normalleştirme, anahtar sırası/whitespace gibi kozmetik farkların “sahte drift” üretmesini azaltır. Diğer şıklar normalleştirme ile ilgili değildir.

Aşağıdakilerden hangisi “over-permission drift” için en uygun sınıflandırma/öncelik örneğidir?

A) Log formatında tarih alanı değişti → Kritik

B) Açıklama/etiket değişti → Kritik

C) Yönetim arayüzüne geniş erişim açıldı → Kritik

D) Küçük bir allow-list’e tek host eklendi → Mutlaka Düşük

E) Kural sırası değişti → Her zaman Düşük

Doğru: C
Gerekçe: Yönetim erişimi genişlemesi saldırı yüzeyini doğrudan büyütür. D/E bağlama göre orta olabilir; A/B genellikle düşük.

Intent-based yönetimde AI/ML önerileri için en doğru güvenlik yaklaşımı hangisidir?

A) Öneri geldiyse otomatik uygula; insan onayı gerekmez

B) Öneriyi kanıt say; doğrulama testine gerek yok

C) Öneriyi hipotez say; guardrail + insan onayı + doğrulama kapısıyla uygula

D) Öneriyi tamamen devre dışı bırak; SDN’de AI kullanılmaz

E) Öneriyi uygulayıp audit log tutmak yeterlidir; rollback gerekmez

Doğru: C
Gerekçe: AI önerisi kanıt değildir; doğrulama ve geri dönüş disiplini şarttır. A/B/E riskli; D aşırı genelleyici.

Bir olayda “drift var” deniyor; ancak audit loglarda ilgili zaman penceresinde hiçbir değişiklik kaydı yok. En doğru ilk yorum hangisidir?

A) Drift kesin yoktur

B) Logging/audit kapsamı yetersiz olabilir; önce görünürlük boşluğunu değerlendirmek gerekir

C) Data plane bozulmuştur; kontrol plane önemsizdir

D) Wireshark tek başına yeterli kanıttır

E) Sorun mutlaka DNS’tir

Doğru: B
Gerekçe: Log yokluğu “değişiklik yok” anlamına gelmez; görünürlük körlüğü olabilir. A kesin hüküm; C/D/E tek nedene yığılır.

Control plane’i “kritik varlık” yapan temel neden aşağıdakilerden hangisidir?

A) Data plane’in her zaman TLS kullanması

B) Tek bir politika hatasının çok hızlı ve geniş etkiyle yayılabilmesi

C) Her drift’in yalnızca etiketten kaynaklanması

D) Wireshark’ın controller’ı otomatik analiz etmesi

E) RESTCONF’un yalnızca HTTP kullanması

Doğru: B
Gerekçe: SDN’de merkezileşme, yanlış değişikliğin yayılım etkisini büyütür. A/D/E alakasız; C yanlış.

Aşağıdakilerden hangisi “kanıt zinciri” açısından en iyi pratiktir?

A) Snapshot al, sonra dosyayı düzenleyip rapora ekle

B) Hash üretme; dosya adı yeterli

C) Orijinal snapshot’ı değişmeden sakla, canonical çıktıyı ayrı tut, her ikisinin hash’ini kaydet

D) Yalnızca ekran görüntüsü al; dosyaya gerek yok

E) Diff dosyasını saklamaya gerek yok

Doğru: C
Gerekçe: Orijinal kanıtın değişmezliği + türetilmiş çıktının ayrımı + hash, izlenebilirlik sağlar.

OpenFlow portlarına dair aşağıdakilerden hangisi en doğru ifadedir?

A) OpenFlow yalnızca UDP kullanır

B) OpenFlow için iyi bilinen TCP portları 6633 ve 6653’tür

C) OpenFlow’un varsayılanı 22’dir

D) OpenFlow yalnızca 830 portunu kullanır

E) OpenFlow portu her zaman 443’tür

Doğru: B
Gerekçe: OpenFlow trafiği için 6633/6653 iyi bilinen TCP portları olarak anılır. Diğerleri yanlış eşleştirme.

Drift tespit runbook’unda “korelasyon kontrolü” adımı neden vazgeçilmezdir?

A) Çünkü diff çıktısını otomatik düzeltir

B) Çünkü drift tespitini yalnızca Wireshark ile yapar

C) Çünkü değişiklik zamanı ile belirti/alarmlar örtüşmüyorsa drift hipotezini zayıflatır ve yanlış yönlenmeyi azaltır

D) Çünkü her olayın nedeni otomasyondur

E) Çünkü rollback’i gereksiz kılar

Doğru: C
Gerekçe: Korelasyon, hipotez doğrulama/çürütme için kritik; yanlış pozitif drift yorumunu azaltır.

Aşağıdaki seçeneklerden hangisi “do not harm” ilkesine en uygun doğrulama yaklaşımıdır?

A) Geniş port aralığında tarama yaparak tüm servisleri keşfetmek

B) Tekil hedef/tekil serviste Test-NetConnection veya curl/openssl ile doğrulama yapmak

C) Üretimde yoğun trafik üretip IDS tepkisini ölçmek

D) Kontrolcünün yazma API’leriyle hızlıca kural ekleyip denemek

E) Rastgele segmentler arası akışlar oluşturarak “ne olur” görmek

Doğru: B
Gerekçe: Tekil servis doğrulaması düşük risklidir ve kanıt üretimine uygundur. A/C/D/E servis kesintisi ve suistimal riskini büyütür.

Bu modülde neler öğrendik?

SDN’de control plane / data plane ayrımının güvenlikte neden “kritik varlık” kavramını güçlendirdiğini.
Merkezi politikanın hem avantajlarını hem de “tek hatanın büyük etki” riskini.
Policy drift’in tipik kaynaklarını ve drift’i snapshot + diff + audit log + tekil doğrulama ile kanıtlamayı.
SDN ekosistemini ürün bağımsız bileşenlerle okuyabilmeyi; northbound/southbound risklerini doğru konumlandırmayı.
Intent-based yönetimde AI/ML önerilerinin “kanıt değil hipotez” olduğunu; guardrail + insan onayı + doğrulama gerekliliğini.
Golden Policy yaklaşımıyla drift tespiti için uygulanabilir runbook ve “Bulgu → Etki → Öneri → Kanıt (rapor formatı)” disiplinini.

MODÜL 8 — İzleme, Loglama, Trafik Analizi ve SIEM’e Hazırlık

Kavramsal şema: çoklu kaynaktan log ve akış verisi; güvenli toplama; şema ve zamanla normalizasyon; SIEM’de korelasyon; çıktıda operasyonel olay ve kanıt disiplini.

Bu modül, ağ güvenliğinde “kontrol koydum” demenin yetmediği noktayı hedefler: görünürlük (visibility). Bir olay olduğunda (veya olay olmadan önce) doğru soruyu sorabilmek için; hangi cihazın hangi kaydı ürettiğini, bu kaydın nasıl standartlaştırılıp toplanacağını, PCAP/Flow gibi trafik verilerinin hangi durumda kanıt sayılacağını ve SIEM’e hazırlık için hangi disiplinlerin şart olduğunu öğrenirsin. Odak; geniş tarama/atak değil, izinli ortamda düşük riskli veri toplama, çıktı okuryazarlığı, karşı kanıt (bu belirtiyi ne doğrular, ne çürütür?) ve kanıt zinciridir. Wireshark ve tcpdump burada “yakalamak için değil, doğru yerde doğru kadar yakalayıp doğru okumak için” kullanılır. IDS/NDR çıktıları (Zeek/Suricata/Snort) “kesin hüküm” değil, hipotez üreten sensörler olarak ele alınır. Modülün sonunda, log kaynaklarını mantıklı bir haritaya oturtup, tek bir senaryoda PCAP ile Flow’un neyi kanıtlayıp neyi kanıtlayamadığını karşılaştırabilir ve Zeek/Suricata çıktılarından savunma kararı üretecek seviyeye gelirsin.

Bu Dersin Hedefleri

Network log kaynaklarını (FW/ACL, router/switch, DNS/DHCP, VPN, proxy/SWG, IDS/NDR, Flow/PCAP) “ne üretir, neyi kanıtlar?” bakışıyla sınıflandırmak.
Syslog disiplinini format + alan standardı + severity + zaman doğruluğu + ayrıştırılabilirlik ekseninde kurmak.
PCAP vs Flow seçiminde ölçek–gizlilik–kanıt niteliği dengesini doğru kurmak.
Wireshark’ta orta/ileri seviyede filtreleme + istatistik ekranları (Conversations/Endpoints) + Expert Info + Follow Stream okuryazarlığıyla kanıt üretmek.
tcpdump ile dar kapsam + kısa pencere + ring buffer + snaplen yaklaşımıyla “do not harm” uyumlu yakalama tasarlamak.
Zeek/Suricata/Snort çıktılarında kritik alanları okuyup pivot ederek kanıt seti oluşturmak.
Arkime ile PCAP arşivleme/arama yaklaşımını ve erişim/retention disiplinini kurmak.
SIEM’e hazırlık için entegrasyon haritası + PCAP/Flow karşılaştırması + çıktı okuma runbook’u üretmek.

Ana içerik

8.1 Network log kaynakları

Hızlı özet: tek kaynakla karar verilmez; kimlik, erişim kararı, davranış ve ham paket kanıtı birlikte okunur.

Kimlik bağlamı

VPN + DHCP (+DNS) zinciri “kim yaptı?” sorusunu hızlandırır.

Davranış bağlamı

FW/Proxy/Flow/IDS birlikte okununca olayın yönü netleşir.

Kaynak seçimi (hızlı karar)

Soru	İlk kaynak	İkinci kaynak
Kim yaptı?	VPN/DHCP	DNS
Neden engellendi?	FW/Proxy	Flow
Gerçekte ne oldu?	Flow	Seçici PCAP

Network görünürlüğü tek kaynaktan gelmez; her kaynak farklı bir “göz”dür ve farklı türde kanıt üretir:

Perimetre/Segment FW/ACL: allow/deny, NAT, kural eşleşmesi, uygulama/URL kategorisi (varsa), kullanıcı/kimlik bağlamı (entegreyse)
Router/Switch: interface durumları, route değişimleri, port up/down, error counters, (opsiyonel) NetFlow/IPFIX export
DNS/DHCP: isim çözümleme ve IP atama zinciri (kim hangi IP’yi aldı? hangi isim çözüldü?)
VPN: kim ne zaman bağlandı, hangi profille, hangi IP havuzuyla, hangi posture/cihaz kimliğiyle (varsa)
Proxy/SWG: web istekleri, kategoriler, TLS inspection durumu (varsa), block nedenleri
IDS/NDR (Zeek/Suricata/Snort): imza/heuristic/anomali sinyalleri, protokol meta verisi, akış ilişkileri
Flow: “kim-kiminle-ne kadar-ne zaman?” görünürlüğü (ölçekli)
PCAP: ham paket gerçekliği (derin), fakat maliyeti ve gizlilik etkisi yüksek

Örnek: çok kaynaklı kesit (uydurma)

bash — korelasyon için paralel kesitler

# FW (deny/allow + kural) 2026-02-10T09:18:21Z host-fw01 app=fw action=DENY src=198.51.100.20 dst=203.0.113.30 proto=tcp dpt=443 rule=SEG-API-DB # DNS (istemci → sorgu) 2026-02-10T09:18:22Z dns01 query=api.example.net client=198.51.100.20 rcode=NOERROR # Flow (özet — kim-kiminle-ne kadar) 2026-02-10T09:18:20–09:21:20Z SRC=198.51.100.20 DST=203.0.113.30 DPT=443 BYTES=184320 DURATION=180s

Etki / risk

Yanlış kaynak seçimi olayı görememeye (kör nokta) yol açar.
Aşırı veri toplamak gizlilik/retention maliyetini büyütür, analiz kapasitesini boğar.
Kimlik bağlamı yoksa (kullanıcı/cihaz) aksiyon gecikir; “kim yaptı?” sorusu havada kalır.

Tespit sinyali / kanıt

Güçlü kanıt çoğu zaman en az 2–3 kaynağın korelasyonu ile oluşur: ör. FW deny + DNS sorgusu + Flow artışı.
Kanıt niteliği: zaman damgası tutarlılığı, kaynak güvenilirliği, bütünlük (hash), tekrar üretilebilirlik.

Savunma kontrolü / düzeltme yaklaşımı

Kaynakları “toplayacağım” diye değil, “hangi soruya cevap verecek?” diye seç.
Olay türüne göre eşle: kimlik (VPN/DHCP), erişim kararı (FW), içerik/işlem (proxy), protokol davranışı (Zeek), ölçek (Flow), ham gerçek (PCAP).
Zaman senkronu + etiketleme (env/site/device) + retention politikasını en başta standardize et.

Dikkat: Tek sensöre aşırı güven yanlış pozitif/negatif riskini artırır. Her sinyal için “ne doğrular, ne çürütür?” sorusu masada olmalı.

8.2 Syslog standardı ve disiplin

Hızlı özet: parse edilemeyen log, görünmeyen olay demektir. Şema, zaman ve severity disiplini bu bölümün çekirdeğidir.

Syslog kalite kontrol matrisi

Kontrol	Beklenen	Kırmızı bayrak
Zaman	UTC/tek standart	Kaynaklar arasında dakika sapması
Şema	Alan isimleri sabit	Cihaz bazlı dağınık format
Severity	Anlamlı sınıflama	Kritik olayların düşük önemde kalması

Syslog, cihazların olay kayıtlarını merkezi bir noktaya iletmek için kullanılan yaygın yaklaşımdır. Burada mesele “syslog kullanıyorum” değil; format tutarlılığı, severity disiplini, zaman doğruluğu ve ayrıştırılabilirliktir. Syslog mesajında “priority (PRI)” alanı facility ve severity bileşenlerini taşır; facility 0–23, severity 0–7 aralığındadır ve PRI = (facility × 8) + severity şeklinde ifade edilir.

Etki / risk

Tutarsız format → SIEM parse edemez → olay görünmez olur.
Yanlış severity → gürültü artar → kritik sinyal kaybolur.
Zaman hatası → korelasyon bozulur → yanlış karar riski.

Tespit sinyali / kanıt

Aynı olayın farklı cihazlarda farklı isimle/formatla görünmesi.
Parse hataları, eksik alanlar, anormal timestamp sapmaları.

Savunma kontrolü / düzeltme yaklaşımı

Zaman standardı: UTC veya kurum standardı; her yerde tutarlı.
Alan standardı: en azından timestamp, host, app, action, src, dst, proto, port, rule/policy, reason, user(opsiyonel) gibi bir “minimum alan seti”.
Taşıma güvenliği: “gerekliyse” daha güvenli taşıma tercihleri (örn. TLS) ve kayıp için kuyruk/buffer yaklaşımı. Syslog-over-TLS için IANA’nın atadığı port 6514 kullanımı yaygındır.
“Gereksiz detay” değil, soru cevaplayan alanlar hedeflenir.

İpucu: Syslog’u “metin” gibi değil, “şema” gibi düşün. SIEM hazırlığı, bu şemayı kararlı hale getirmektir.

Uydurma syslog satırı (format okuryazarlığı)

bash — örnek kayıt (grep/parse için)

soc@siem-prep:~$ grep SEG-API-DB /var/log/remote/fw-structured.log | tail -n 1 2026-02-10T09:18:21Z host-fw01 app=fw action=DENY src=198.51.100.20 dst=203.0.113.30 proto=tcp dpt=443 rule=SEG-API-DB reason=policy_no_match

8.3 Trafik verisi türleri (PCAP vs Flow)

Hızlı özet: varsayılan yaklaşım Flow ile geniş görünürlük, seçici PCAP ile derin kanıttır.

Kriter	Flow	PCAP
Ölçek	Yüksek	Düşük-Orta
Derinlik	Meta veri	Paket detayı
Maliyet/gizlilik	Daha düşük	Daha yüksek
Tipik kullanım	Triage ve trend	Kök neden kanıtı

PCAP: Paket seviyesinde ham yakalama. “Ne konuşuldu?” sorusuna en yakın veri; ancak depolama, gizlilik ve işlem maliyeti yüksektir.
Flow (NetFlow/IPFIX): Akış özeti. “Kim kiminle, ne kadar, ne zaman?” sorusuna ölçeklenebilir yanıt; içerik yoktur ya da sınırlıdır.

Etki / risk

PCAP güçlü kanıt sunar; yanlış yakalama stratejisi gizlilik riskini ve operasyonel yükü artırır.
Flow ölçekli görünürlük sağlar; ancak içerik kanıtı sınırlı olduğu için bazı olaylarda tek başına yeterli değildir.

Tespit sinyali / kanıt

Flow: sıra dışı hedef çeşitliliği, beklenmeyen portlar, anormal byte/packet oranları, uzun süreli bağlantılar.
PCAP: protokol hataları, TLS handshake sorunları, DNS davranışı, reset/retransmission örüntüleri.

Savunma kontrolü / düzeltme yaklaşımı

Varsayılan strateji: Flow ile geniş görünürlük + seçici PCAP ile derin kanıt.
PCAP yakalama: dar hedef + dar servis + kısa pencere + snaplen + ring buffer.
Kanıt paketi: Flow özetleri + kısa PCAP kesiti + ilgili loglar birlikte.

Dikkat: PCAP “her şeyi yakalamak” değildir. Kanıt için doğru an ve doğru akış yakalanır.

Örnek: Flow triage vs PCAP özet (kavramsal)

Flow (nfdump — örnek)

bash — flow triage

netops@flow:~$ nfdump -R /data/nfcapd -t 2026/02/10.09:00-09:30 -n 5 -o fmt:%ts %sa %da %dp %byt 2026-02-10 09:18:21 198.51.100.20 203.0.113.30 443 184320 # Ölçekli yön: “kim-kiminle-ne kadar”

PCAP (tshark — özet)

tshark — seçici dosya üzerinde

analist@host:~/evidence$ tshark -r ./case/evidence_short.pcap -q -z conv,tcp 198.51.100.20:51422 <-> 203.0.113.30:443 frames=210 bytes=184320 duration=180s # Derin kanıt: protokol davranışı ve paket düzeyi

8.4 Wireshark (orta/ileri kullanım)

Hızlı özet: önce konuşma özeti, sonra hata sinyali, en son paket detayı; ters sıra analiz maliyetini büyütür.

Wireshark okuma sırası

Adım	Eylem
1	Conversations/Endpoints ile kim-kiminle konuşuyor kontrol et.
2	Expert Information ile retransmission/reset gibi sinyalleri ayıkla.
3	Yalnız gerekli akışlarda paket detayına in.

Wireshark, “paket görmek” değil; doğru ekranlarda doğru soruyu sorarak protokol okuryazarlığı ve kanıt üretimi yapmaktır.

Etki / risk

Yanlış filtre / yanlış zaman penceresi → alakasız veri yığını → analiz felci.
Şifreli trafikte “içerik” beklentisi → yanlış varsayım.
Üretimde kontrolsüz capture → gizlilik ve operasyon riski.

Tespit sinyali / kanıt

Statistics → Conversations/Endpoints: kim kiminle konuşuyor, hacim ne?
Analyze → Expert Information: retransmission, malformed packet, reset, zero window vb.
Follow Stream: şifreli değilse veya sadece meta/akış okunacaksa faydalı.

Savunma kontrolü / düzeltme yaklaşımı

Önce “kim-kiminle” (Conversations), sonra “ne oldu” (Expert Info), en son “detay” (paket alanları).
Şifreli trafikte bile zaman/hacim/uç korelasyonu güçlü kanıttır.

Örnek display filter’lar (dar kapsam):

ip.addr == 203.0.113.30
tcp.port == 443
dns
tls.handshake.type == 1 (ClientHello korelasyonu)

Wireshark — display filter + özet

# Filter bar (örnek) ip.addr == 203.0.113.30 && tcp.port == 443 # Statistics → Conversations (özet metin) 198.51.100.20:52431 <-> 203.0.113.30:443 Packets A→B: 105 B→A: 105 Bytes: 184320 # Expert Information: retransmission / dup ack / reset sinyalleri triage için

İpucu: Büyük PCAP’lerde GUI zorlanıyorsa önce “özet çıkar”: Conversations/Endpoints, ardından gerekirse tshark ile istatistik üret; kanıt için çoğu zaman ham paketlere inmeden karar verilebilir.

8.5 tcpdump (operasyonel kullanım)

Hızlı özet: dar hedef + kısa pencere + limitli dosya yaklaşımı, “do not harm” için temel pratiktir.

Yakalama politikası (özet)

Kapsam: tek hedef + tek servis.
Süre: kısa pencere + ring buffer.
Bütünlük: pcap dosyası + hash + komut notu birlikte saklanır.

tcpdump, düşük seviyede ama çok güçlü bir yakalama aracıdır. Operasyonel kullanım; dar kapsam, kısa pencere, ring buffer, minimal risk prensibiyle yürür.

Örnek: dar kapsam + ring buffer (izinli ortam)

tcpdump — kontrollü yakalama

analist@sensor:~$ sudo tcpdump -i eth0 -nn -s 96 -C 20 -W 5 host 203.0.113.30 and tcp port 443 -w ./evidence/pcap_ring_%Y%m%d%H%M%S.pcap # -C/-W: dosya boyutu ve dosya sayısı sınırı; olay penceresine göre süreyi kısalt.

Etki / risk

Uzun süre/ geniş kapsam capture → disk dolması, gizlilik riski, analiz yükü.
Yanlış arayüz seçimi → “hiçbir şey yakalamadım” yanılgısı.
Snaplen yanlış seçilirse kritik alanlar kesilir veya gereksiz veri artar.

Tespit sinyali / kanıt

Kısa PCAP kesiti + komut satırı çıktısı notu + hash ile bütünlük.
BPF filtreleriyle hedef/servis daraltma (ör. tek hedef + tek port).

Savunma kontrolü / düzeltme yaklaşımı

Ring buffer ile dosya boyutu/sayısı limitli yakalama.
“Olay penceresi” etrafında daraltılmış zaman aralığı.
Kanıt paketleme: pcap + özet + hash + kısa açıklama.

Dikkat: tcpdump “yakalamak” kadar “nerede ve ne kadar yakalayacağını bilmek” işidir.

8.6 IDS/NDR araçları: çıktı okuryazarlığı (Zeek/Suricata/Snort)

Hızlı özet: alarm sonuç değil hipotezdir; bağımsız log/flow/pcap ile doğrulanmadan karar verilmez.

Araç	Pivot alanı	İlk doğrulama
Suricata	signature, severity, flow_id	FW kararı + Flow zaman eşleşmesi
Zeek	uid, id.orig_h/id.resp_h, SNI	DNS/FW korelasyonu
Snort	alert sınıfı ve öncelik	Bağımsız log kesiti

IDS/NDR sensörleri “kesin hüküm” değil; sinyal üretir. Amaç: sinyali okuyup doğrulamak, bağlama oturtmak ve kanıta çevirmektir.

Etki / risk

Körü körüne alarm → yanlış pozitiflerle ekip tükenir.
Alarmı yok sayma → yanlış negatif riski.
Sensör konumlandırması hatalıysa (yanlış TAP/SPAN) görünürlük eksik kalır.

Tespit sinyali / kanıt (kritik alanlar)

Suricata (eve.json): timestamp, src_ip, dest_ip, proto, alert.signature, alert.severity, flow_id
Zeek (conn.log/dns.log/ssl.log): süre, servis, yön, byte/packet, query/rcode, TLS SNI/cert meta
Snort: alert metni, öncelik, sınıflandırma, akış bilgisi

Savunma kontrolü / düzeltme yaklaşımı

Alarmı “hipotez” kabul et; en az bir bağımsız kaynakla doğrula (FW log, Flow, DNS, kısa PCAP).
Tuning disiplini: gürültü kaynaklarını tanımla, istisna/eşik değişikliklerini kontrollü sürümle.
Kanıta çevirme: ilgili log satırları + pivot anahtarları + zaman çizelgesi.

Dikkat: Bu alanlar “saldırı nasıl yapılır?” için değil; “ne oldu?” sorusunu yanıtlamak içindir.

Örnek çıktı kesitleri (uydurma)

bash — sensör çıktıları

# Zeek conn.log (tek satır) 198.51.100.20 203.0.113.30 443 tcp 180.5s 184320B orig_pkts=105 resp_pkts=105 # Suricata eve.json (alert özeti) {"event_type":"alert","src_ip":"198.51.100.20","dest_ip":"203.0.113.30","alert":{"signature":"ET POLICY ...","severity":2},"flow_id":4829103}

8.7 PCAP arşivleme & arama (Arkime)

Hızlı özet: aranabilirlik ve retention yönetimi yoksa PCAP yalnızca maliyet üretir.

Operasyonel minimumlar

Rol bazlı erişim (RBAC) olmadan PCAP erişimi açılmaz.
Retention süresi risk/maliyet dengesine göre sabitlenir.
Kanıt paylaşımında kısa kesit + hash standardı zorunludur.

PCAP değerli ama “aranabilir” değilse operasyonel yük olur. Arkime, PCAP’leri oturum (session) mantığıyla indeksleyip aramayı kolaylaştırır. Literatürde Arkime’nin “Moloch” adıyla da anıldığı kaynaklar bulunur.

Örnek: oturum araması (API / kavramsal)

bash — Arkime REST (örnek)

soc@arkime-client:~$ curl -sS -H "Authorization: Bearer <token>" "https://arkime.example/api/sessions?expression=ip==198.51.100.20%20%26%26%20port==443&date=1h" | jq '.data[0] | {startTime, srcIp, dstIp, node}' { "startTime": 1770722301000, "srcIp": "198.51.100.20", "dstIp": "203.0.113.30", "node": "capture-prod-01" } # Gerçek kurulumda URL, auth ve alan adları sürüme göre değişir.

Etki / risk

İndeks yoksa: “PCAP var ama bulamıyorum.”
Retention yönetilmezse maliyet ve gizlilik riski büyür.
Erişim kontrolü zayıfsa kanıt verisi yanlış kişilere açılabilir.

Tespit sinyali / kanıt

Zaman/host/port etrafında session aramasıyla ilgili kesite hızlı erişim.
Kanıt: session özeti + kısa pcap kesiti + hash.

Savunma kontrolü / düzeltme yaklaşımı

Retention: süre + disk bütçesi + kritik segment önceliği.
Erişim: rol bazlı, “kanıt verisi” prensibi.
“Kısa kesit” prensibi: olay için gereken minimum PCAP.

8.8 Flow & trafik görselleştirme (opsiyonel)

Hızlı özet: görselleştirme karar verdirmez; triage yönü verir. Ham flow satırıyla birlikte kullanılmalıdır.

Görsel çıktıyı doğrulama

Görsel bulgu	Doğrulama
Top destination artışı	Ham flow satırlarıyla zaman ve hacim kontrolü
Port dağılımında sıçrama	FW/IDS loguyla port bağlamı eşleştirme
Egress trend anomali	Baseline dönemiyle karşılaştırma

Flow verisi ham halde dağınıktır; görselleştirme anomaliyi ve trendi hızlı görmeyi sağlar (top talkers, top destinations, port dağılımı, zaman serisi artışları).

Etki / risk

Görsel özet triage hızını artırır.
Yanlış agregasyon yanlış sonuca götürebilir.

Tespit sinyali / kanıt

Top talkers, top destinations, port dağılımı, beklenmeyen egress artışı.
Kanıt: grafik/özet tablo + ham flow satırı örneği + zaman damgası.

Savunma kontrolü / düzeltme yaklaşımı

Agregasyon kararını açık yaz: “5 dk bucket”, “src/dst+port”, “internal/external”.
Görsel özet ham kaydı ikame etmez; sadece yön verir.
Opsiyonel ekosistem örnekleri: ntopng, ElastiFlow, nfdump/NfSen (araç seçimi kurum ölçeğine göre).

Örnek: ham flow satırı (nfdump — uydurma)

bash — görseli doğrulamak için ham kayıt

netops@collector:~$ nfdump -R /var/nfdump/prod -t 2026/02/10.10:10-10:25 'host 198.51.100.20' -o line 2026-02-10 10:12:05 198.51.100.20:51422 -> 203.0.113.30:443 6 210 184320 180.000s

8.9 Kurumsal izleme (opsiyonel)

Hızlı özet: güvenlik sinyali ile operasyon sağlığı aynı zaman çizelgesinde okunmadan doğru teşhis zorlaşır.

Sağlık sinyali

CPU, bellek, interface hata oranı ve gecikme.

Güvenlik sinyali

Alert, deny oranı, anomali ve akış sapması.

Kurumsal izleme; cihaz sağlığı (up/down), kapasite (CPU/mem/iface), servis duruşu ve güvenlik sinyallerinin tek operasyonel resimde birleşmesidir.

Etki / risk

Sağlık metrikleri yoksa güvenlik olayı “performans sorunu” gibi görünür (yanlış teşhis).
Aşırı alarm ve yanlış eşikler gerçek olayı maskeler.

Tespit sinyali / kanıt

Interface error artışı + retransmission artışı + uygulama timeout → ağ sağlığı kaynaklı olabilir.
Güvenlik ve operasyon metrikleri aynı zaman çizelgesinde okunmalıdır.

Savunma kontrolü / düzeltme yaklaşımı

Alarm hijyeni: eşik + korelasyon + bakım penceresi.
Opsiyonel ekosistem örnekleri: Zabbix, Grafana + Prometheus, PRTG, LibreNMS, Nagios.

Örnek: metrik sorgusu (Prometheus — kavramsal)

bash — Grafana/Prometheus ile aynı zaman ekseni

sre@mon:~$ curl -sG http://prometheus.example/api/v1/query --data-urlencode 'query=rate(node_network_receive_err_total[5m])' {"status":"success","data":{"result":[{"metric":{"device":"eth0"},"value":[1770722400,"0.12"]}]}} # Güvenlik uyarısı ile interface error/retransmit aynı grafikte okunur.

8.10 Komut & Araç Okuryazarlığı (Windows / Linux / macOS)

Hızlı özet: komutların amacı saldırı değil; zaman standardı, kanıt üretimi, tekil doğrulama ve bütünlüktür.

Hızlı komut seti (özet)

Adım	Windows	Linux/macOS
Zaman kontrolü	`w32tm /query /status`	`timedatectl status` / `systemsetup -getusingnetworktime`
Log dışa aktarma	`Get-WinEvent ... \| Export-Csv`	`journalctl --since ...` / `log show --last 2h`
Tekil test	`Test-NetConnection ... -Port 443`	`curl -I ...` / `nc -vz ... 443`
Bütünlük	`Get-FileHash ... -Algorithm SHA256`	`sha256sum ...` / `shasum -a 256 ...`

Aşağıdaki komutlar yalnızca denetim/okuma, tekil hedef/tekil servis doğrulama ve kanıt üretimi/bütünlüğü içindir. Tüm örnekler uydurma ve dokümantasyon IP bloklarıyla verilmiştir.

1. Zaman standardı ve korelasyon ön şartı

Windows (PowerShell / CMD)

PowerShell - zaman kontrolü

PS C:\evidence> w32tm /query /status

Amaç: Saat kaynağı ve senkron durumunu denetlemek (korelasyon için ön koşul).
Beklenen çıktı: Kaynak, offset, son senkron zamanı.
Yorum ipucu: Büyük offset korelasyonu bozar; loglarda “olaydan önce log düşmüş” gibi görünür.
Güvenli sınır: Okuma.

Linux

bash - zaman kontrolü

analist@host:~/evidence$ timedatectl status

Amaç: Sistem saati / NTP senkron durumu kontrolü.
Beklenen çıktı: NTP aktif mi, saat dilimi, senkron bilgisi.
Yorum ipucu: “System clock synchronized” alanı korelasyon için kritiktir.
Güvenli sınır: Okuma.

macOS

zsh - network time

analist@macbook:~/evidence$ systemsetup -getusingnetworktime

Amaç: Ağ zamanı kullanımı açık mı?
Beklenen çıktı: On/Off.
Yorum ipucu: Kapalıysa zaman sapması olasılığı yükselir.
Güvenli sınır: Okuma (komut yönetici yetkisi isteyebilir).

2. Log okuma ve kanıta alma (zaman penceresiyle)

Windows (PowerShell)

PowerShell - son 2 saat System log

PS C:\evidence> $start = (Get-Date).AddHours(-2) PS C:\evidence> Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start} | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message | Export-Csv .\evidence\windows_system_events.csv -NoTypeInformation -Encoding UTF8

Amaç: Zaman penceresinde olayları kanıta almak.
Beklenen çıktı: CSV kanıt dosyası.
Yorum ipucu: TimeCreated + ProviderName + Id pivot için anahtar; saat sapması varsa korelasyon çöker.
Güvenli sınır: Yerel, okuma.

Linux

bash - journal dışa aktarma

analist@host:~/evidence$ sudo journalctl --since "2 hours ago" --no-pager > ./evidence/journal_last2h.log

Amaç: Zaman penceresinde logları dışa aktarmak.
Beklenen çıktı: Metin log dosyası.
Yorum ipucu: Host/app alanlarını ayıkla; aynı olayı başka kaynakla eşleştirecek anahtarları not al.
Güvenli sınır: Okuma.

macOS

zsh - unified log dışa aktarma

analist@macbook:~/evidence$ log show --last 2h --style compact > ./evidence/macos_log_last2h.txt

Amaç: Unified logging’den kanıt kesiti almak.
Beklenen çıktı: Metin dosyası.
Yorum ipucu: Saat sapması şüphesinde önce zaman standardını doğrula.
Güvenli sınır: Okuma.

3. Tekil hedef / tekil servis doğrulaması (do not harm)

Windows (PowerShell)

PowerShell - tekil 443 testi

PS C:\evidence> Test-NetConnection 203.0.113.30 -Port 443

Amaç: Tek hedef + tek port bağlantı doğrulaması.
Beklenen çıktı: TcpTestSucceeded True/False ve name resolution bilgisi.
Yorum ipucu: NameResolutionSucceeded ile TCP başarısını ayır (DNS mi, yol mu, port mu?).
Güvenli sınır: Tek hedef + tek port; izinli ortam.

Linux

bash - tekil URL testi

analist@host:~/evidence$ curl -I https://example.net --max-time 5

Amaç: Tek URL için hızlı erişilebilirlik doğrulaması (başlık al).
Beklenen çıktı: HTTP durum kodu / TLS hatası.
Yorum ipucu: TLS hatası “sertifika/handshake” hipotezini güçlendirir; ağ kesintisiyle karıştırma.
Güvenli sınır: Tekil doğrulama; yoğunluk yok.

macOS

zsh - tekil port testi

analist@macbook:~/evidence$ nc -vz 203.0.113.30 443

Amaç: Tek hedef + tek port bağlantı kontrolü.
Beklenen çıktı: succeeded/failed.
Yorum ipucu: Başarısızsa PCAP/Flow ile “deneme var mı?” diye karşı kanıt ara.
Güvenli sınır: Tek hedef + tek port.

4. Kontrollü PCAP üretimi ve bütünlük

Linux (tcpdump, dar kapsam + ring buffer)

bash - dar kapsam tcpdump

analist@host:~/evidence$ sudo tcpdump -i eth0 -nn -s 96 -C 20 -W 5 host 203.0.113.30 and tcp port 443 -w ./evidence/pcap_tls_203.0.113.30_443_%Y%m%d%H%M%S.pcap

Amaç: Dar hedef + dar servis + ring buffer ile kontrollü kanıt üretmek.
Beklenen çıktı: Birden fazla küçük pcap dosyası.
Yorum ipucu: Snaplen çok küçükse kritik başlıklar kesilebilir; çok büyükse gereksiz veri artar.
Güvenli sınır: İzinli ortam, dar kapsam, kısa pencere.

macOS (tcpdump, dar kapsam)

zsh - dar kapsam tcpdump

analist@macbook:~/evidence$ sudo tcpdump -i en0 -nn -s 96 host 203.0.113.30 and tcp port 443 -w ./evidence/macos_tls_203.0.113.30_443.pcap

Amaç / çıktı / ipucu / sınır: Linux ile aynı mantık.

Windows (Wireshark kuruluysa dumpcap ile dar kapsam)

PowerShell - dumpcap

PS C:\evidence> dumpcap -i 1 -a duration:60 -f "host 203.0.113.30 and tcp port 443" -w .\evidence\win_tls_203.0.113.30_443.pcapng

Amaç: 60 saniyelik, dar filtreli capture.
Beklenen çıktı: pcapng dosyası.
Yorum ipucu: Süreyi kısa tut; olay penceresine hizala.
Güvenli sınır: Yerel/izinli, kısa süre, dar filtre.

Bütünlük (hash)

Windows: Get-FileHash .\evidence\win_tls_203.0.113.30_443.pcapng -Algorithm SHA256
Linux: sha256sum ./evidence/*.pcap > ./evidence/pcap_hashes.sha256
macOS: shasum -a 256 ./evidence/macos_tls_203.0.113.30_443.pcap > ./evidence/macos_pcap.sha256

Kanıt notu (operasyon disiplini)

Hash tek başına yetmez; dosya adı + zaman penceresi + hangi filtreyle alındığı + kim topladı bilgisiyle birlikte rapora girer.

5. Wireshark: okuma → kanıta çevirme mini rehberi

Nereden başlarım?

Capture stratejisi: tek hedef + tek servis + kısa pencere.
İlk özet: Statistics → Conversations / Endpoints.
Anomali sinyali: Analyze → Expert Information.
Gerekirse akış: Follow Stream (şifreli değilse).

Nasıl okurum?

Conversations: uç çiftleri, byte/packet, süre → “kim-kiminle-ne kadar”
Expert Info: retransmission/dup ack/reset/zero window → “performans mı, kesinti mi?”
TLS’de içerik yerine: handshake, SNI, zaman/hacim korelasyonu

Nasıl kanıta çeviririm?

Conversations tablosu ekran görüntüsü + “hangi filtreyle?” notu
İlgili paket numarası + timestamp + eşleşen syslog/flow satırı
“Gözlem” (ne görüyorum) ve “yorum” (ne anlama geliyor) ayrımını raporda koru

6. tshark ile hızlı özet (GUI'siz kanıt çıktısı)

bash - tshark özet

analist@host:~/evidence$ tshark -r ./evidence/sample.pcap -q -z conv,tcp > ./evidence/tshark_tcp_conversations.txt

Amaç: PCAP’ten konuşma özetini çıkarıp kanıta dönüştürmek.
Beklenen çıktı: Metin özet.
Yorum ipucu: En çok konuşan uçlar + süre/byte ilişkisi triage’da değerlidir.
Güvenli sınır: Okuma; pcap üzerinde.

7. Zeek / Suricata: çıktı okuryazarlığı (pivot anahtarları)

Zeek (PCAP'ten log üretimi - izinli/yerel)

bash - zeek offline

analist@host:~/evidence$ zeek -r ./evidence/sample.pcap

Amaç: PCAP’ten yapılandırılmış meta loglar üretmek (conn/dns/ssl vb.).
Beklenen çıktı: conn.log, dns.log, ssl.log gibi dosyalar.
Yorum ipucu: Pivot için id.orig_h, id.resp_h, zaman, uid, server_name (SNI) alanlarını kullan.
Güvenli sınır: Yerel analiz; saldırı/istismar yok.

Suricata (PCAP üzerinde offline inceleme - izinli/yerel)

bash - suricata offline

analist@host:~/evidence$ suricata -r ./evidence/sample.pcap -l ./evidence/suri_out

Amaç: PCAP’ten alert/meta çıktısı üretmek (ör. eve.json).
Beklenen çıktı: eve.json ve ilgili loglar.
Yorum ipucu: flow_id, alert.signature, alert.severity, src_ip/dest_ip ile korelasyon kur.
Güvenli sınır: Yerel analiz; saldırı/istismar yok.

Alert kesitini daraltma (okuma/kanıt)

bash - jq alert özeti

analist@host:~/evidence$ jq 'select(.event_type=="alert") | {timestamp,src_ip,dest_ip,proto,alert:{signature,severity},flow_id}' ./evidence/suri_out/eve.json > ./evidence/suricata_alerts_summary.json

Amaç: Kanıta girecek minimum alan setini çıkarmak.
Beklenen çıktı: Özet JSON.
Yorum ipucu: “Gereksiz detay” yerine korelasyon anahtarlarını sakla.
Güvenli sınır: Okuma.

8. Kanıt paketleme (dosya + hash + paket hash)

Windows

PowerShell - paketleme ve hash

PS C:\evidence> Compress-Archive -Path .\evidence\* -DestinationPath .\evidence_pack.zip PS C:\evidence> Get-FileHash .\evidence_pack.zip -Algorithm SHA256

Linux / macOS

bash - paketleme ve hash

analist@host:~/evidence$ tar -czf ./evidence_pack.tar.gz ./evidence analist@host:~/evidence$ sha256sum ./evidence_pack.tar.gz > ./evidence_pack.sha256

Amaç: Dağınık kanıtları tek pakette toplamak ve bütünlüğünü kanıtlamak.
Yorum ipucu: Paket hash’i rapordaki “Kanıt” bölümünün omurgasıdır.
Güvenli sınır: Yerel dosya işlemleri.

8.11 HOW-TO: Log Kaynakları Entegrasyon Haritası (Runbook / Şablon)

Runbook sonucu: her log kaynağı için sahiplik, alan seti, taşıma, retention ve kanıt notu tek tabloda sürümlenir.

Amaç: “Hangi log nereden geliyor, nasıl taşınıyor, SIEM’de hangi şemayla tutuluyor?” sorusunu tek bir haritaya indirgemek.

Hazırlık

Kapsam (izinli): segmentler, cihaz tipleri, kritik uygulamalar.
Zaman standardı: UTC mi kurum saati mi? (tek olmalı)
Minimum alan seti: timestamp, device_id, src, dst, proto, port, action, rule/policy, reason, user(opsiyonel)
Sahiplik: Her kaynak için “owner” (kim sorumlu) tanımla.

Uygulama (şablon)

Aşağıdaki tabloyu “tek doğru kaynak” yap (sürümle):

Kaynak	Ürettiği veri	Kritik alanlar	Taşıma / etiket	Retention	Owner
FW	Allow/Deny, NAT	action, rule, src/dst/port	syslog, type=fw	90 gün	NetSec
DNS	query/rcode	client_ip, query, rcode	syslog/agent, type=dns	30 gün	IT Ops
VPN	auth/session	user, profile, assigned_ip	api/syslog, type=vpn	180 gün	IAM
IDS/NDR	alert/meta	signature, severity, flow_id	file/agent, type=ids	30-90 gün	SOC
Flow	Akış özeti	bytes, packets, duration	exporter, type=flow	30 gün	NetOps
PCAP	Ham paket	pcap file + hash	arkime, type=pcap	7-30 gün	SOC

Örnek: normalize edilmiş olay (SIEM ingest — uydurma)

bash — tek kayıt üzerinde alan kontrolü

soc@siem-prep:~$ echo '{"ts":"2026-02-10T10:12:06Z","host":"host-fw01","type":"fw","src":"198.51.100.20","dst":"203.0.113.30","action":"ALLOW","rule":"EGRESS-APP-HTTPS"}' | jq -c '{ts,host,type,src,dst,action,rule}' {"ts":"2026-02-10T10:12:06Z","host":"host-fw01","type":"fw","src":"198.51.100.20","dst":"203.0.113.30","action":"ALLOW","rule":"EGRESS-APP-HTTPS"} # Timestamp + type + src/dst tutarlıysa korelasyon kuralları güvenilir çalışır.

Doğrulama

Her kaynak için 3 örnek kayıt al; SIEM’de doğru parse oluyor mu?
Timestamp + host/app alanları tutarlı mı?
Aynı olayı en az iki kaynaktan korele edebiliyor musun? (FW ↔ Flow gibi)

Kanıt paketleme

Harita dokümanı + örnek log kesitleri + (varsa) parse ekran görüntüsü
Paket hash’i üret ve rapora ekle

Geri dönüş / Rollback

Haritayı sürümle (v1.0 → v1.1).
Parse/etiket değişikliği sorun çıkarırsa önceki sürüme dön.

8.12 HOW-TO: PCAP vs Flow Tek Senaryo Karşılaştırması (Runbook)

Runbook sonucu: aynı olayda Flow triage, PCAP doğrulama kanıtı üretir; ikisi birlikte karar kalitesini artırır.

Senaryo tipi: “Bir sunucudan dışarıya beklenmeyen TLS bağlantıları” (izinli/uydurma).

Hazırlık

İncelenecek varlık: srv-app01 (uydurma) → IP: 198.51.100.20
Zaman penceresi: alarm etrafında ±15 dk
Hedef: Flow ile geniş resim, PCAP ile seçici kanıt

Uygulama

Adım	Eylem
1	Flow ile triage: kim-kiminle-ne kadar-ne zaman sorusunu yanıtla.
2	Uydurma örnek: `SRC=198.51.100.20 DST=203.0.113.30 DPT=443 BYTES=184320 DURATION=180s`
3	Seçici PCAP yakala: yalnız hedef `203.0.113.30:443`, kısa pencere, ring buffer.
4	PCAP’te TLS handshake, reset, hata paternlerini doğrula.
5	Şifreli trafikte içerik yerine protokol davranışı + zaman/hacim kanıtı üret.

Örnek terminal oturumları (aynı senaryo IP’leri)

Flow triage

nfdump — özet

netops@flow:~$ nfdump -R /var/nfdump -t 2026/02/10.10:00-10:30 -c 20 'src host 198.51.100.20 and dst host 203.0.113.30 and dst port 443' 2026-02-10 10:12:05 198.51.100.20:51422 -> 203.0.113.30:443 ... 184320 bytes 180.00s

Seçici PCAP

tcpdump — dar filtre

analist@sensor:~$ sudo tcpdump -i eth0 -nn -s 128 -w ./evidence/srv_tls_443.pcap host 203.0.113.30 and tcp port 443 -G 60 -W 1 # 60 sn pencere; tek dosya; olay öncesi/sonrası zamanı not al.

Doğrulama

Flow zamanı ile PCAP zamanı eşleşiyor mu?
FW/proxy logu aynı bağlantıyı görüyor mu?

Kanıt paketleme

Flow özet dosyası + kısa pcap + tshark/wireshark özet çıktısı + hash’ler

Geri dönüş / Rollback

Yakalama kapsamını “refleksle” büyütme.
Kanıt yetmiyorsa önce farklı kaynakla güçlendir (FW/DNS/Proxy), sonra kontrollü yeni pencereyle tekrar yakala.

8.13 HOW-TO: Zeek/Suricata Çıktı Okuma Runbook’u

Runbook sonucu: alarmdan rapora giden yol; pivot anahtarları ve karşı kanıt kontrolüyle standardize edilir.

Amaç: Bir alert/sinyal geldiğinde “okuyup karar üretebilmek”.

Hazırlık

Sensör konumu/kapsam: hangi segmenti görüyor?
Olay penceresi: ±10–15 dk
Pivot anahtarları: src/dst, flow_id, timestamp, signature, (DNS ise) query

Uygulama

Adım	Eylem
1	Alarmı özetle: Suricata signature/severity + Zeek conn/dns/ssl bağlamını çıkar.
2	Pivot et: aynı src/dst için FW kararı, DNS çözümü, Flow hacmi ve süreyi eşleştir.
3	Gerekirse kısa PCAP kesiti ile protokol davranışını doğrula.
4	Karşı kanıt kontrolü: trafik baseline içinde mi, değişiklik penceresi etkisi var mı?

Örnek: offline üretim ve hızlı özet

bash — Zeek + Suricata (izinli pcap)

analist@ids:~$ zeek -r ./evidence/srv_tls_443.pcap conn.log ssl.log dns.log ... yazıldı. analist@ids:~$ suricata -r ./evidence/srv_tls_443.pcap -l ./evidence/suri_run analist@ids:~$ jq 'select(.event_type=="alert") | {timestamp,src_ip,dest_ip,alert}' ./evidence/suri_run/eve.json | head -n 3 # Pivot: flow_id / signature / zaman ile FW ve Flow satırlarını eşle.

Doğrulama

En az iki bağımsız kaynaktan aynı olayı doğrula.
Alarm tek başına “kesin” kabul edilmez.

Kanıt paketleme

Alarm satırı + korelasyon logları + flow özeti + (varsa) kısa pcap
Hash + 3–6 satırlık zaman çizelgesi

Geri dönüş / Rollback

Yanlış pozitif: tuning kaydı aç (hangi koşulda yanlış üretti?)
Şüphe artarsa: yetkili süreçlerle containment seçeneklerini tetikle (karar/rapor disipliniyle).

8.14 Operasyonel Senaryo (ileri seviye — izinli/uydurma)

Senaryo odağı: anomaliyi meşru trafikten ayırmak için baseline, korelasyon ve kontrollü kanıt seti birlikte değerlendirilir.

Belirti

198.51.100.20 (uydurma uygulama sunucusu) dışarıya 203.0.113.30:443 hedefinde kısa aralıklarla TLS bağlantıları kuruyor. İzleme ekranında “anomalous egress” benzeri bir uyarı görüldü.

Hipotezler

1.Meşru değişiklik / yeni entegrasyon: Uygulama güncellemesi yeni bir dış servise bağlanıyor.

2.Egress kontrol zayıflığı (farkındalık): Beklenmeyen hedeflere çıkış mümkün olduğu için risk artmış olabilir.

3.Yanlış pozitif: Baseline’da var; görselleştirme yalnızca “alışılmadık” göstermiş olabilir.

4.Ağ sağlığı etkisi: Retransmission/reset nedeniyle yeniden deniyor (güvenlik değil operasyon).

Toplanacak kanıt

Flow özeti (zaman/hacim)
FW logu (allow/deny + kural)
Zeek ssl.log/conn.log veya Suricata alert (varsa)
Kısa PCAP kesiti (tek hedef/tek servis) + Wireshark Conversations/Expert Info çıktısı
Hash’ler (bütünlük)

Uydurma kanıt kesitleri

(A) Flow özeti

flow — özet satırlar

2026-02-10T10:12:05Z SRC=198.51.100.20 DST=203.0.113.30 SPT=51422 DPT=443 BYTES=184320 PACKETS=210 DURATION=180s

(B) FW log

syslog — structured

2026-02-10T10:12:06Z host-fw01 app=fw action=ALLOW src=198.51.100.20 dst=203.0.113.30 proto=tcp dpt=443 rule=EGRESS-APP-HTTPS reason=policy_match

zeek — ssl alanları

2026-02-10T10:12:07Z id.orig_h=198.51.100.20 id.resp_h=203.0.113.30 server_name=api.example.net version=TLSv1.3 resumed=F

(D) Wireshark / tshark özeti

tshark — conv,tcp (özet)

analist@host:~/evidence$ tshark -r ./case/egress_tls.pcap -q -z conv,tcp | head -n 8 198.51.100.20:51422 <-> 203.0.113.30:443 frames=210 bytes≈184320 duration≈180s # Tek yönlü byte artışı: triage’da içerik yerine hacim/zaman kanıtı.

Analiz adımları

Adım	Soru / eylem	Örnek sonuç (bu senaryo)
1	Korelasyon: Flow ↔ FW ↔ Zeek aynı pencerede mi?	Evet (±1–2 sn)
2	Meşruiyet: `server_name` / hedef envanterde mi?	Envanter ile eşleştir
3	Karşı kanıt: geçmiş baseline’da da var mı?	Flow/Zeek geçmişi
4	Operasyon: Expert Info’da retransmit/reset?	Varsa performans hipotezi
5	Risk: hedef baseline dışı mı?	Egress kontrol kaydı (gerekirse)

Karar

Meşru hedef (planlı entegrasyon) ise: Alarm yanlış pozitif; tuning + envanter güncellemesi önerilir.
Meşru değil / baseline dışı ise: Olay kaydı açılır; egress politikası gözden geçirilir ve ilgili log kapsamı güçlendirilir (yetkili süreçle).

Rapor (Bulgu → Etki → Öneri → Kanıt)

Bulgu: 198.51.100.20 sunucusunun 203.0.113.30:443 hedefine TLS bağlantıları kurduğu; Flow, FW ve Zeek kayıtlarıyla aynı zaman penceresinde doğrulandı.
Etki: Hedef meşru değilse veri çıkışı/iletişim riski; meşru ise izleme sistemlerinde gürültü ve yanlış alarm maliyeti.
Öneri:

İzinli dış hedef listesi/entegrasyon envanterini güncel tut; korelasyonda kullan.

Egress kural setini “minimum gerekli” yaklaşımıyla periyodik gözden geçir.

Sensör tuning: trafik meşruysa gürültüyü azalt; değilse korelasyon koşullarını güçlendir.

Kanıt: Flow özeti, FW allow logu, Zeek TLS meta kaydı, Wireshark Conversations/Expert Info özeti ve dosya hash’leri.

Terimler Sözlüğü

Terim Türkçe karşılığı / açıklama

Syslog Cihazların olay kayıtlarını merkezi toplama sistemlerine iletme yaklaşımı; PRI içinde facility+severity taşır

Facility Syslog’ta mesaj kaynağı sınıfı (0–23)

Severity Syslog’ta önem derecesi (0–7)

SIEM Farklı kaynaklardan logları toplayıp korelasyon/alarm üreten merkezi sistem

PCAP Paket yakalama dosyası; ham trafik verisi

Flow (NetFlow/IPFIX) Akış özet kayıtları; kim-kiminle-ne kadar-ne-zaman görünürlüğü

Retention Log/PCAP verisini saklama süresi ve politikası

Triage Olayı hızlı sınıflandırma ve ilk aksiyonların belirlenmesi

Pivot Bir kayıttan yola çıkıp ilişkili kayıtlara genişleme

Zeek Protokol meta verisi üreten NDR yaklaşımı; conn/dns/ssl gibi loglarla çalışır

Suricata IDS/IPS motoru; olayları/alert’leri (örn. eve.json) üretir

Snort İmza tabanlı IDS yaklaşımı; alert üretir

Arkime PCAP arşivleme ve oturum bazlı arama/indeksleme yaklaşımı (Moloch adıyla da anılır)

Ring Buffer Yakalamayı dosya boyutu/sayısıyla sınırlayıp taşmayı önleyen döngüsel kayıt yöntemi

Snaplen Paketin ne kadarının yakalanacağını belirleyen uzunluk; gereksiz veri toplama riskini yönetir

Kendini Değerlendir

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

Bir olayda “kimin ne yaptığı” sorusuna en hızlı kimlik bağlamını sağlama ihtiyacı doğdu. Aşağıdaki kaynak kombinasyonlarından hangisi bu ihtiyacı en doğru şekilde karşılar?

A) PCAP + Flow

B) VPN + DHCP (+ gerekirse DNS)

C) IDS alert + PCAP

D) Router interface log + Flow

E) Proxy kategorileri + Flow

Doğru: B
Gerekçe: Kimlik bağlamı (kullanıcı/cihaz/atanan IP) çoğu zaman VPN ve DHCP’den gelir; DNS bunu “hangi isim” boyutuyla destekler. Diğerleri hacim/ham trafik sağlar ama kimliği doğrudan vermez.

Syslog disiplininde “parse edilebilirlik” en çok hangi tasarım hatasıyla bozulur?

A) Logların UTC yerine yerel saatle yazılması

B) Her cihazın farklı alan adları ve farklı düzenle log basması

C) Severity değerinin yüksek seçilmesi

D) Logların yalnızca kısa süre saklanması

E) Flow verisinin tutulmaması

Doğru: B
Gerekçe: SIEM’in doğru parse etmesi için şema/alan standardı şarttır; saat standardı önemli olsa da parse edilebilirliği doğrudan “alan tutarlılığı” kadar yıkıcı bozmaz.

PCAP ve Flow seçiminde aşağıdakilerden hangisi en doğru “varsayılan strateji” yaklaşımıdır?

A) Sadece PCAP, çünkü kesin kanıttır

B) Sadece Flow, çünkü ölçeklidir

C) Flow ile geniş görünürlük + seçici PCAP ile derin kanıt

D) Sadece IDS alert’leri, çünkü “tehdit” üretir

E) Sadece proxy logları, çünkü uygulama düzeyi görür

Doğru: C
Gerekçe: Flow ölçekli yön verir; PCAP seçici derin kanıt sağlar. Tek kaynağa yaslanmak kör nokta veya maliyet/gizlilik riski doğurur.

Wireshark’ta bir TLS trafiği için “içerik göremiyorum” şikâyeti geldi. En doğru yaklaşım hangisidir?

A) PCAP’i büyütmek için yakalama süresini uzatmak

B) Şifreli trafiği çözmek için genel amaçlı “kırma” yöntemlerine yönelmek

C) İçerik yerine davranış kanıtı üretmek: handshake, SNI, zaman/hacim, uç korelasyonu

D) Tüm trafiği filtresiz yakalayıp “sonra bakmak”

E) Sadece Follow Stream ekranına bakmak

Doğru: C
Gerekçe: Modül yaklaşımı şifreli trafikte “davranış/metadata” kanıtını öne çıkarır; diğer seçenekler ya riskli ya da analiz yükünü büyütür.

tcpdump ile “do not harm” uyumlu yakalama tasarımında en kritik üçlü hangisidir?

A) Uzun süre + geniş kapsam + büyük snaplen

B) Dar hedef/servis + kısa pencere + ring buffer (gerekirse uygun snaplen)

C) DNS çözümleme açık + verbose açık + filtresiz

D) Tüm portlar + tüm hedefler + sınırsız dosya

E) Sadece -s 0 kullanmak

Doğru: B
Gerekçe: Operasyonel güvenlik, kapsamı ve süreyi daraltmayı; disk ve gizlilik riskini ring buffer ile kontrol etmeyi gerektirir.

Suricata alert’i geldi. “Kesin olay” kararı vermeden önce en doğru doğrulama yolu hangisidir?

A) Alert metnine göre doğrudan engelleme yapmak

B) Aynı src/dst için FW log + Flow + (gerekirse) kısa PCAP ile korelasyon kurmak

C) Alarmı yok saymak

D) Sadece Snort’a bakmak

E) Sadece Zeek’e bakmak

Doğru: B
Gerekçe: Alarm hipotezdir; bağımsız kaynaklarla doğrulama ve karşı kanıt arama modülün temel disiplinidir.

“Timestamp sapması” nedeniyle korelasyon tutarsız görünüyor. Aşağıdaki bulgulardan hangisi doğrudan zaman senkronu problemine işaret eder?

A) Flow’da byte artışı

B) PCAP’te TLS ClientHello görülmesi

C) Aynı olayın bir cihazda “gelecekte”, diğerinde “geçmişte” loglanması

D) IDS’de yüksek severity

E) Proxy’de kategori bilgisi

Doğru: C
Gerekçe: Olayın kronolojisinin ters görünmesi, saat kaynağı/senkron problemine tipik işarettir.

Arkime gibi PCAP arşivleme yaklaşımında en kritik risk kontrol çifti hangisidir?

A) Daha uzun retention + herkese açık erişim

B) Role dayalı erişim + minimum gerekli kesit yaklaşımı

C) Daha fazla indeks + filtresiz arama

D) Sadece GUI kullanım zorunluluğu + sınırsız saklama

E) Alert üretimi + otomatik engelleme

Doğru: B
Gerekçe: PCAP “kanıt verisi”dir; erişim kontrolü ve veri minimizasyonu gizlilik ve suistimal riskini düşürür.

Flow görselleştirmede yanlış agregasyon hangi hataya en çok yol açar?

A) Hash üretilememesi

B) SIEM’in tamamen çalışmaması

C) Yanlış sonuç/yanlış yönlenme (anomali var sanma veya kaçırma)

D) PCAP dosyasının bozulması

E) Syslog PRI hesabının değişmesi

Doğru: C
Gerekçe: Görselleştirme yön verir; yanlış bucket/anahtar seçimi yanlış hikâye üretir.

“Bulgu → Etki → Öneri → Kanıt” formatında en zayıf rapor bileşeni aşağıdakilerden hangisidir?

A) Bulgu: “Flow’da egress arttı”

B) Etki: “Hedef meşru değilse veri çıkışı riski”

C) Öneri: “Entegrasyon envanterini güncelle ve egress’i gözden geçir”

D) Kanıt: “Ekranda gördüm, hatırlıyorum”

E) Kanıt: “Flow satırı + FW log satırı + Zeek kesiti + hash”

Doğru: D
Gerekçe: “Hatırlıyorum” denetlenebilir kanıt değildir; kanıt bölümünde izlenebilir kayıtlar ve bütünlük (hash) bulunmalıdır.

Bu modülde neler öğrendik?

Network log kaynaklarını “hangi soruya cevap verir?” mantığıyla seçmeyi ve korelasyon kurmayı.
Syslog’ta şema/alan standardı + severity disiplini + zaman doğruluğunun SIEM başarısını belirlediğini.
PCAP ve Flow’un güçlü/zayıf yönlerini; ölçek–gizlilik–kanıt dengesinde doğru seçmeyi.
Wireshark’ta Conversations/Endpoints, Expert Info ve filtrelerle “kanıt okuryazarlığı” üretmeyi.
tcpdump ile dar kapsamlı, ring-buffer ve düşük riskli yakalama stratejisi kurmayı.
Zeek/Suricata/Snort çıktılarında pivot anahtarlarıyla bağlam toplayıp karar üretebilmeyi.
Arkime yaklaşımıyla PCAP’in aranabilir hale gelmesinde retention/erişim disiplininin önemini.

MODÜL 9 — Kablosuz Ağ Güvenliği

Kavramsal şema: istemcilerin kurumsal AP ile güvenli ilişkilendirmesi; yayın alanı ve politika katmanı; aynı SSID ile kopya yüzey (evil twin) ve kablosuz tehdit izinin NAC/MDM/WIDS ile bağlanması.

Kablosuz ağ güvenliği “şifre koydum bitti” değildir; kurumsal kimlik doğrulama (802.1X/RADIUS), erişim politikası (rol/cihaz bazlı), segmentasyon (kurumsal–misafir–IoT ayrımı), RF gerçekleri (kapsama/roaming/gürültü) ve görünürlük (WLC/RADIUS/istemci logları) birlikte yönetilmek zorundadır. Bu modülde hedef, Wi-Fi’ı kurumsal bir operasyon gibi ele almak: güvenli tasarım, kontrollü yayın, güvenli istemci profilleri, değişiklik disiplini ve “olay olduğunda kanıt üretebilme”. Rogue AP/Evil Twin gibi riskler cracking/istismar anlatmadan; sinyal (SSID/BSSID/kanal) + log (WLC/RADIUS/istemci) + politika (baseline/whitelist) üçlüsüyle yönetilir. Yeni nesil Wi-Fi 7 (IEEE 802.11be) ile gelen kabiliyetler (ör. daha geniş kanallar ve çoklu bağlantı yaklaşımı) kapasiteyi artırırken görünürlük ve değişiklik yönetimi ihtiyacını da büyütür.

Modül sonunda, kurumsal Wi-Fi kontrol setini doğru seçebilecek; sahada zarar vermeyen denetim/okuma ile sinyalleri toplayıp kanıta çevirebilecek; Rogue AP/Evil Twin şüphelerinde playbook ile ilerleyip Bulgu → Etki → Öneri → Kanıt (rapor formatı) üretebileceksin.

Bu Dersin Hedefleri

Kurumsal Wi-Fi yaklaşımını (kimlik, segmentasyon, politika, yönetim düzlemi, loglama) bütüncül tasarlayabileceksin.
Rogue AP ile Evil Twin risklerini ayırt edip “risk yönetimi + kanıt üretimi” perspektifiyle ele alabileceksin.
Wi-Fi 7’nin (802.11be) ve ufukta Wi-Fi 8’in (802.11bn) operasyon/görünürlük etkilerini kavramsal yorumlayabileceksin.
Windows/Linux/macOS üzerinde SSID/BSSID/kanal/güvenlik türü gibi kritik sinyalleri güvenli şekilde toplayabileceksin.
Kablosuz saha araçlarını (survey/izleme/WIDS benzeri/WLC ekosistemi) “hangi soruya cevap verir?” mantığıyla konumlandırabileceksin.
Rogue AP/Evil Twin şüphesinde cracking olmadan, çoklu kaynaktan doğrulama + karşı-kanıt ile playbook uygulayabileceksin.
Kanıt paketleme disiplinini (zaman penceresi, minimum veri, bütünlük hash’i, notlandırma) kablosuz olaylara uyarlayabileceksin.

Ana içerik

9.1 Kurumsal Wi-Fi yaklaşımı

Kurumsal yaklaşım; Wi-Fi’ı “tek SSID” değil, kimlik + politika + mimari + operasyon olarak ele almaktır.

Kimlik ve erişim

802.1X/RADIUS; rol bazlı yetkilendirme; AAA ile muhasebe ve izlenebilirlik.

Segmentasyon

Kurumsal, misafir ve IoT/OT SSID’lerini ayrı politika ve ağ bölümlerine ayırma.

Yönetim ve görünürlük

WLC/AP olayları, association/roaming, EAP hataları, captive portal; merkezi log.

İstemci profili

Sertifika doğrulama, MDM ile otomatik bağlanma disiplini, misafir profil ayrımı.

Etki / risk

Paylaşımlı anahtar (PSK) mantığı kurumsal ölçekte izlenebilirliği ve anahtar hijyenini zorlaştırır: kim “yaptı?” sorusu pahalılaşır, şifre rotasyonu operasyonel yük üretir, sızıntı riski artar.
Zayıf segmentasyon, kablosuz kaynaklı bir olayı büyütür (etki alanı genişler).
Yönetim düzlemi zayıfsa hedef “istemci” değil “altyapının kontrolü” olabilir (farkındalık düzeyi).

Tespit sinyali / kanıt

WLC/Controller: yeni AP görünümü, SSID parametre değişikliği, disassoc/deauth dalgaları, istemci yoğunluk anomalileri.
RADIUS/AAA: kısa sürede artan auth failure, sertifika doğrulama hataları, aynı kullanıcı için çoklu deneme örüntüleri.
İstemci tarafı: “sertifika uyarısı”, SSID güvenlik türünün beklenmedik görünmesi, ani captive portal davranışı.

Savunma kontrolü / düzeltme yaklaşımı

Kurumsal SSID’lerde kimlik temelli model (802.1X) + istemci profil sertliği (sertifika doğrulama) uygula.
Misafir ağını internete çıkışla sınırlı ve izole tasarla; “kimlik/politika” ile hangi sınıfın hangi segmente gideceğini netleştir.
Log korelasyonunu baştan tasarla: WLC + RADIUS + (varsa) DHCP/DNS + Flow/NDR. (Modül 8’in “log entegrasyon haritası” refleksi burada doğrudan işine yarar.)

Dikkat: Kablosuzda en pahalı hata, “sorun RF mi güvenlik mi?” ayrımını yapmadan aksiyon almaktır. Önce belirtiyi doğrulayacak/çürütecek minimum kanıt setini seç.

9.2 Rogue AP / Evil Twin risk yönetimi

İki riski karıştırmayın: Rogue AP yetkisiz altyapı; Evil Twin aynı SSID ile kullanıcıyı yanlış yüzeye çekme sinyali (nasıl yapılır değil; kanıt düzeyi).

Rogue AP

Kurumun bilgisi/izni olmadan kurulan erişim noktası; çoğu zaman iç ağa beklenmeyen bir giriş yaratır.

Evil Twin

Meşru SSID’yi taklit eden sahte yayın; sinyal + merkez log + istemci olayı üçlüsüyle yönetilir.

Etki / risk

Rogue AP, segmentasyon/NAC mantığını boşa düşürebilecek “yan yol” yaratabilir (kontrol boşluğu).
Evil Twin, özellikle istemci profilleri zayıfsa (sertifika doğrulaması gevşek, otomatik bağlanma agresif) kimlik/oturum riskini büyütür.

Tespit sinyali / kanıt

Saha sinyali: Aynı SSID için beklenmeyen BSSID (envanter dışı) en kritik göstergedir.
Parametre tutarsızlığı: Kurumsal SSID’nin güvenlik türünün beklenmedik görünmesi (ör. enterprise beklenirken “open/PSK” gibi raporlanması).
Sertifika uyarıları: 802.1X’te beklenmeyen sunucu sertifikası/kimlik doğrulama uyarıları.
Kablolu ipuçları (kavramsal): Bir switch portu arkasında anormal çoklu MAC görünmesi veya standart dışı üretici/OUI izleri (tek başına hüküm değil; doğrulama için pivot).

Savunma kontrolü / düzeltme yaklaşımı

Baseline/Altın liste: Yetkili SSID’ler + beklenen güvenlik türleri + AP envanteri (BSSID/konum/kanal planı) + WLC kayıtları.
İstemci profil sertliği: Sertifika doğrulaması, otomatik bağlanma kuralları, “benzer SSID” riskini azaltan politikalar.
WIDS/WIPS & izleme: Yetkisiz yayın ve SSID taklidi sinyallerini otomatik yakalayan sensörler + olay prosedürü.
Karşı-kanıt zorunluluğu: “SSID değişti” şüphesinde önce değişiklik kaydı/planlı bakım var mı kontrol et; RF parazit/roaming artışı gibi masum nedenleri dışla.

İpucu: Rogue/Evil Twin tespitinde en iyi pratik: saha sinyali (SSID/BSSID/kanal) + merkez log (WLC/RADIUS) + istemci olayı üçlüsü. Tek kaynağa dayanma.

9.3 Yeni nesil Wi-Fi görünümü (kavramsal)

Standart evrimi performans getirir; operasyon tarafında ise uyumluluk, izleme ve değişiklik yönetimi zorunludur.

Wi-Fi 7 (802.11be)

PHY/MAC kabiliyetleri; kapasite ve yoğun ortam verimliliği.

Wi-Fi 8 (802.11bn)

Ufuk: Ultra High Reliability (UHR); güvenilirlik ve kararlılık metrikleri.

OWE / Enhanced Open

Misafir senaryolarında opportunistic şifreleme ile “açık ağ” riskini azaltma.

Etki / risk

Yeni kabiliyetler (daha geniş kanal seçenekleri vb.) yoğun ortamlarda performans sağlarken, izleme uyumluluğu (sensör/driver/AP firmware) ve değişiklik yönetimi ihtiyacını büyütür.
“Güvenlik olayı sandığın şey” bazen RF/roaming kaynaklı olabilir: bu yüzden RF metrikleriyle (SNR/retry/roam reason) güvenlik sinyallerini birlikte yorumlama gerekir.
Misafir ağlarında, şifreleme/izolasyon doğru tasarlanmazsa kullanıcı riskleri artar; Enhanced Open gibi yaklaşımlar bu riski azaltmayı hedefler.

Tespit sinyali / kanıt

Band/kanal geçişleriyle korele kopmalar (RF olasılığı).
Eski sensör/driver’ların 6 GHz gibi ortamlarda “eksik/yanlış raporlama” üretmesi (görünürlük açığı).
Misafir ağlarında beklenmeyen captive portal davranışları, DNS anormallikleri gibi istemci sinyalleri.

Savunma kontrolü / düzeltme yaklaşımı

Yeni nesil kabiliyetleri açmadan önce uyumluluk kontrolü yap: AP firmware, istemci driver, WIDS/WIPS sensör desteği, log alanları.
“Güvenlik mi RF mi?” ayrımı için korelasyon: istemci logu + WLC + RF metrikleri.
Misafir ağlarında risk azaltımı: policy’e uygun şifreleme yaklaşımı (ör. Enhanced Open/OWE değerlendirmesi), segmentasyon ve captive portal güvenliği.

Dikkat: Yeni nesil Wi-Fi’de en büyük hata “özellik aç → bitti” yaklaşımıdır. Her değişiklik, izleme ve kanıt üretimiyle birlikte tasarlanmalı.

9.4 Denetim/okuma komutları

Bu alt başlığın amacı saldırmak değil; sahadaki sinyali zarar vermeden ölçmek ve kanıta dönüştürmektir. Kapsam: SSID, BSSID, kanal, sinyal, güvenlik türü, bağlanma geçmişi ve hata mesajları.

Boyut	Ne toplanır?	Operasyonel anlam
Kimlik	Auth türü, sertifika uyarıları	802.1X ve profil tutarlılığı
Fizik	Kanal, RSSI/SNR, BSSID	RF mi, taklit mi ayrımı
Zaman	Olay penceresi, log zaman damgası	WLC/RADIUS korelasyonu

Etki / risk

Komut çıktısı yoksa “aynı SSID mi, hangi BSSID mi, güvenlik türü tutarlı mı?” soruları yanıtlanamaz; yanlış aksiyon riski doğar.
Kontrolsüz ve geniş kapsamlı toplama gereksiz veri/gizlilik yükü üretir; minimum veri prensibi şarttır.

Tespit sinyali / kanıt

Çok AP’li ortamda aynı SSID için çok BSSID normal olabilir; kritik olan envanter dışı BSSID veya güvenlik parametresi tutarsızlığıdır.
İstemci sertifika uyarısı, beklenmedik captive portal, olay zaman penceresinde artan auth failure.

Savunma kontrolü / düzeltme yaklaşımı

Çıktıyı “hüküm” değil “gözlem” kabul et; WLC/RADIUS ile doğrula.
Kanıt üret: zaman damgası + konum notu + kısa yorum + bütünlük hash’i.

9.5 Kablosuz saha araçları

Saha araçları iki temel soruya hizmet eder: RF/saha gerçekliği ve güvenlik görünürlüğü.

RF / kapsama

Kapsama, parazit, kanal çakışması, roaming; survey ve spectrum.

Güvenlik sinyali

Yetkisiz SSID/BSSID, benzer isim, envanter dışı yayın; WIDS/WIPS.

Örnek araç sınıfları (ekosistem bağımsız)

Survey/heatmap: NetSpot, Ekahau benzeri (kurumsal), vb.
Windows analiz: Acrylic Wi-Fi, inSSIDer/WinFi benzeri
Mobil hızlı kontrol: WiFi Analyzer benzeri
Kurumsal görünürlük: WLC entegre WIDS/WIPS/sensörler

Etki / risk

Survey yoksa kör noktalar oluşur; basit RF sorunu bile “güvenlik olayı” gibi görünür.
Yanlış araç seçimi ya gereksiz detay üretir ya da kritik sinyali kaçırır.

Tespit sinyali / kanıt

Spectrum/Analyzer: sürekli parazit, kanal doluluğu (triage’ı etkiler).
WIDS/WIPS: yetkisiz yayın, SSID taklidi, OUI/üretici tutarsızlığı sinyalleri.
WLC raporları: AP envanter dışı uyarılar, istemci davranış anomalileri.

Savunma kontrolü / düzeltme yaklaşımı

Araçları role göre konumlandır: NOC (RF sağlık) + SOC (sinyal/kanıt) ortak çalışsın.
Her çıktıyı “hangi soruyu cevaplıyor?” etiketiyle sakla; yoksa gürültüye dönüşür.

9.6 Komut & Araç Okuryazarlığı (Windows / Linux / macOS + Wireshark)

Aşağıdaki komutlar yalnızca denetim/okuma, güvenli doğrulama ve kanıt üretimi içindir. Ortak disiplin: kısa zaman penceresi + minimum veri + bütünlük.

Hızlı komut seti (özet)

Adım	Windows	Linux	macOS
Ağ listesi	`netsh wlan show networks mode=bssid`	`nmcli -f SSID,BSSID,CHAN,FREQ,SIGNAL,SECURITY dev wifi list`	`airport -s`
Bağlantı özeti	`netsh wlan show interfaces`	`iw dev wlan0 link`	`airport -I`
Olay logu	`Get-WinEvent` (WLAN AutoConfig)	`journalctl`	`log show`
Bütünlük	`Get-FileHash`	`sha256sum`	`shasum -a 256`

Windows (PowerShell / netsh)

1. Çevredeki Wi-Fi ağlarını BSSID ve kanal ile listele (okuma/kanıt)

PowerShell / netsh

PS C:\evidence> netsh wlan show networks mode=bssid

Amaç: SSID → hangi BSSID’ler, kanal ve kimlik doğrulama/encryption türü görünümü.
Beklenen çıktı türü: Metin liste (SSID/BSSID/Sinyal/Kanal/Auth/Encryption).
Yorum ipucu: SSID + BSSID + Authentication/Encryption + Channel alanları “tutarlılık” için kritik.
Güvenli sınır: Sadece görüntüleme; bağlantı kurma/deneme yok.

2. Mevcut bağlantı detayını gör (okuma/kanıt)

netsh — bağlantı özeti

PS C:\evidence> netsh wlan show interfaces

Amaç: Hangi SSID/BSSID’ye bağlısın, sinyal, radio type, hızlar.
Beklenen çıktı türü: Tek arayüz özet.
Yorum ipucu: “BSSID/Radio type/Signal” olay zaman çizelgesinde pivot olur.
Güvenli sınır: Okuma.

3. WLAN istemci olaylarını zaman penceresiyle dışa aktar (okuma/kanıt)

Get-WinEvent — WLAN AutoConfig

PS C:\evidence> $start = (Get-Date).AddHours(-2); Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-WLAN-AutoConfig/Operational'; StartTime = $start } | Select-Object TimeCreated, Id, LevelDisplayName, Message | Export-Csv .\evidence\wlan_autoconfig_last2h.csv -NoTypeInformation -Encoding UTF8

Amaç: Kopma/bağlanma denemeleri/kimlik doğrulama hataları gibi istemci sinyallerini kanıta almak.
Beklenen çıktı türü: CSV dosyası.
Yorum ipucu: Sertifika doğrulama/kimlik doğrulama ile ilgili hata metinleri ve zaman tutarlılığı.
Güvenli sınır: Yerel okuma; minimum zaman penceresi.

4. Kanıt bütünlüğü hash’i üret (kanıt)

SHA-256 bütünlük

PS C:\evidence> Get-FileHash .\evidence\wlan_autoconfig_last2h.csv -Algorithm SHA256

Amaç: Dosyanın değişmediğini göstermek.
Beklenen çıktı türü: SHA-256 hash.
Yorum ipucu: Hash + dosya adı + üretim zamanı birlikte rapora girer.
Güvenli sınır: Yerel.

Linux (NetworkManager / iw)

1. SSID/BSSID/kanal/sinyal/güvenlik türünü listele (okuma/kanıt)

nmcli — Wi-Fi taraması

analist@soc:~/evidence$ nmcli -f SSID,BSSID,CHAN,FREQ,SIGNAL,SECURITY dev wifi list

Amaç: Saha sinyalini tablo halinde görmek.
Beklenen çıktı türü: Tablo liste.
Yorum ipucu: Aynı SSID için beklenmeyen SECURITY veya envanter dışı BSSID var mı?
Güvenli sınır: Okuma.

2. Bağlı olduğun ağın link bilgisini gör (okuma/kanıt)

iw — bağlantı özeti

analist@soc:~/evidence$ iw dev wlan0 link

Amaç: Bağlı SSID/BSSID, sinyal seviyesi, bağlantı özeti.
Beklenen çıktı türü: Metin.
Yorum ipucu: “Bağlı olunan BSSID” şüpheli roaming/yanlış AP iddiasında kritik.
Güvenli sınır: Okuma.

3. Son 1 saat sistem/ağ olaylarını kanıta al (okuma/kanıt)

journalctl — zaman penceresi

analist@soc:~/evidence$ sudo journalctl --since "1 hour ago" --no-pager > ./evidence/journal_last1h.log

Amaç: İstemci tarafı olaylarını zaman penceresinde saklamak.
Beklenen çıktı türü: Log dosyası.
Yorum ipucu: Bağlantı kopmaları, auth hataları, driver uyarıları.
Güvenli sınır: Yerel; minimum süre.

4. Kanıt seti için hash listesi üret (kanıt)

Çoklu dosya hash

analist@soc:~/evidence$ sha256sum ./evidence/* > ./evidence/evidence_hashes.sha256

Amaç: Çoklu dosya bütünlüğü.
Beklenen çıktı türü: Hash listesi.
Yorum ipucu: Paketlemeden önce hash almak idealdir.
Güvenli sınır: Yerel.

macOS (airport / unified logging)

Aşağıdaki komutlarda airport yardımcı programı için tam yol kullanılır; ortamınıza göre değişebilir.

1. Çevredeki Wi-Fi ağlarını listele (okuma/kanıt)

airport — tarama

analist@MacBook evidence % /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -s

Amaç: SSID, BSSID, RSSI, kanal, güvenlik görünümü.
Beklenen çıktı türü: Tablo.
Yorum ipucu: Envanter dışı BSSID ve güvenlik tutarsızlığına odaklan.
Güvenli sınır: Okuma.

2. Anlık bağlantı bilgisini gör (okuma/kanıt)

airport — bağlantı bilgisi

analist@MacBook evidence % /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I

Amaç: Bağlı BSSID, RSSI/Noise, kanal.
Beklenen çıktı türü: Metin.
Yorum ipucu: RSSI/Noise değişimi “RF mi güvenlik mi?” ayrımında yardımcıdır.
Güvenli sınır: Okuma.

3. Son 2 saat Wi-Fi olaylarını dışa aktar (okuma/kanıt)

unified logging

analist@MacBook evidence % log show --last 2h --style compact > ./evidence/macos_log_last2h.txt

Amaç: Bağlantı denemeleri/kopmalar/sistem mesajları.
Beklenen çıktı türü: Metin dosyası.
Yorum ipucu: Zaman sapması varsa korelasyon bozulur; saat tutarlılığını not et.
Güvenli sınır: Yerel; minimum süre.

4. Kanıt bütünlüğü hash’i (kanıt)

SHA-256

analist@MacBook evidence % shasum -a 256 ./evidence/macos_log_last2h.txt

Amaç: Bütünlük.
Beklenen çıktı türü: SHA-256 hash.
Yorum ipucu: Hash’i raporda “Kanıt” alanına ekle.
Güvenli sınır: Yerel.

Wireshark okuryazarlığı (kablosuz olaylarda “nasıl okurum, nasıl kanıta çeviririm?”)

Sınır: Bu bölüm yalnızca yetkili kurumsal sensör/WLC tarafından alınmış capture veya tamamen yerel/izinli lab capture’ları için düşünülmelidir. “Her yerde dinle” yaklaşımı yoktur.

Nasıl yakalarım? (capture stratejisi)

Kaynak seçimi: Tercihen WLC/AP “diagnostic capture” veya yetkili sensör; yoksa lab ortamında kontrollü yakalama.
Zaman penceresi: Belirti etrafında daralt (örn. ±10–15 dk).
Hedefleme: İlgili SSID/BSSID’lere odaklan; “her şeyi yakala” yok.
Bütünlük: PCAP dosyasını hash’le; dosyaya kısa not ekle (kim/nerede/ne zaman/niçin).

Nasıl okurum? (filtre ve ekranlar)

Hızlı pivotlar: SSID/BSSID’e göre filtreleme (alan adları ortam tipine göre değişebilir; amaç: beacon/probe/association gibi yönetim sinyallerini ayırmak).
Zaman çizelgesinde “kısa sürede anormal yoğunluk” (association/disassociation dalgası) aramak.
Menü/ekran: Statistics → Conversations/Endpoints (hangi BSSID’ler görünür, yoğunluk var mı?).
Statistics → Protocol Hierarchy: yakalanan trafiğin dağılımı “beklenenle” uyumlu mu?
Expert Information: olağandışı tekrar/uyarı sinyallerini hızlı görmek.

Nasıl kanıta çeviririm?

Ekran görüntüsü tek başına yeterli değil; PCAP + özet tablo + hash + kısa yorum paketle.
Rapor için 1–2 küçük “kanıt kesiti” üret: ör. “envanter dışı BSSID’nin aynı SSID adını yayınladığına dair yönetim sinyali” + zaman damgası + karşılaştırma notu (baseline).

9.7 HOW-TO: Rogue AP/Evil Twin Tespit Playbook’u (Cracking yok)

Aşağıdaki playbook yalnızca izinli/kurum içi yetkili ortam veya tamamen yerel lab varsayımıyla; cracking/istismar olmadan, gözlem + doğrulama + kanıt üretimi içindir.

1. Hazırlık

Baseline (altın liste): Yetkili SSID’ler (örn. CorpNet, CorpNet-Guest); her SSID için beklenen güvenlik türü/politika (kurumsal: 802.1X; misafir: policy’e uygun).
AP envanteri: BSSID (MAC), konum, beklenen kanal/bant, WLC kaydı.
Zaman standardı: WLC/RADIUS/istemci saatlerini mümkün olduğunca tutarlı tut (korelasyon).
Pivot anahtarları: SSID, BSSID, kanal/bant, zaman penceresi (±10–15 dk), etkilenen kullanıcı/cihaz sayısı.

2. Uygulama

Belirti sınıflandırması — kullanıcı: “sertifika uyarısı”, “bağlanamıyorum”, “beklenmeyen giriş sayfası”.
Belirti sınıflandırması — SOC/WLC: auth failure artışı, disassoc dalgası, yeni AP uyarısı.
Saha gözlemi (denetim/okuma): Etkilenen noktada SSID listesi + her SSID için BSSID + kanal + güvenlik türü.
Merkez doğrulaması — WLC: O SSID’de yetkili AP’ler hangileri? Şüpheli BSSID envanterde var mı?
Merkez doğrulaması — RADIUS: Aynı zaman penceresinde failure türleri ne? (sertifika doğrulama / kimlik / timeout)

3. Doğrulama (çoklu kaynak + karşı-kanıt)

Karşı-kanıt: Planlı bakım/değişiklik var mı?
Karşı-kanıt: RF tarafında parazit/roaming artışı var mı (retry/roam reason)?
Karar mantığı (örnek): Envanter dışı BSSID + güvenlik türü tutarsız + istemci sertifika uyarısı birlikteyse → Evil Twin şüphesi güçlenir.
Envanter dışı AP’nin kurumsal altyapıda “yetkisiz cihaz” olarak görülmesi (WLC/varlık yönetimi) → Rogue AP şüphesi güçlenir.

4. Kanıt paketleme

Saha komut çıktıları (SSID/BSSID/kanal/güvenlik türü).
WLC olay kesiti (format uydurma olabilir; içerik gerçek veri olmasın).
RADIUS olay kesiti.
3–6 satırlık zaman çizelgesi.
Dosya hash’leri (SHA-256).
Her dosya için: kim aldı, nerede aldı, ne zaman aldı, hangi amaçla aldı notu.

5. Geri dönüş / rollback

Yanlış pozitifse: Baseline’ı güncelle (yeni AP devreye alındıysa envantere ekle), izleme kurallarını tuning et, değişiklik yönetimini iyileştir.
Şüphe güçleniyorsa (yetkili süreçle): Saha inceleme talebi aç, kullanıcı iletişimi yayınla (“sertifika uyarısı görürsen bağlanma”), ilgili SSID istemci profillerini ve politikaları sıkılaştır.

9.8 Operasyonel Senaryo (izinli/uydurma)

Senaryo uydurma verilerle örneklendirilmiştir; amaç suç atfetmek değil, kanıt zinciriyle doğru hipotezi bulmaktır.

Belirti

Kampüste kullanıcılar CorpNet SSID’sine bağlanırken beklenmeyen sertifika uyarısı gördüklerini, bazı cihazların kısa süreli “giriş sayfası” benzeri davranış yaşadığını bildiriyor.

Toplanacak kanıt

Saha: SSID/BSSID/kanal/güvenlik (netsh, nmcli, airport)
WLC kesiti: parametre, yeni AP, association trendi
RADIUS: failure türleri
İstemci WLAN olayları (son 2 saat) + SHA-256

Hipotez tablosu

#	Hipotez	Not
1	Planlı değişiklik	RADIUS sertifika yenilemesi; bazı cihaz profilleri güncellenmemiş olabilir (meşru).
2	Evil Twin	Aynı SSID’yi taklit eden envanter dışı yayın.
3	RF / roaming	Kanal karmaşası; kararsız roaming, uyarı yan etki.
4	Misafir politika karışması	Captive portal yanlış SSID’ye uygulanıyor olabilir.

Uydurma kanıt kesitleri (örnek)

(A) Saha gözlemi — CorpNet

Yetkili küme: 02:11:22:33:44:55, 02:11:22:33:44:66 → güvenlik: Enterprise
Şüpheli: 02:aa:bb:cc:dd:ee → Open gibi raporlanıyor (tutarsız)

(B) RADIUS (uydurma)

Örnek log satırı

2026-02-10T08:08:12Z user=E12345 result=FAIL reason=server_cert_untrusted ssid=CorpNet client_ip=198.51.100.20

(C) WLC (uydurma)

Örnek olay

2026-02-10T08:07:55Z event=client_assoc ssid=CorpNet ap_bssid=02:aa:bb:cc:dd:ee rssi=-40

Analiz adımları

Korelasyon: Sertifika uyarısı zamanı ↔ RADIUS server_cert_untrusted ↔ şüpheli BSSID association aynı pencereye oturuyor mu?
Karşı-kanıt: Planlı sertifika yenilemesi/değişiklik kaydı var mı? WLC konfig değişimi var mı?
Doğrulama: Şüpheli BSSID yetkili listede yoksa ve sahada güvenlik türü tutarsızsa şüphe güçlenir.
RF ihtimali: Aynı pencerede diğer SSID’lerde benzer kopma/retry artışı var mı?

Karar

Envanter dışı BSSID + tutarsız güvenlik + sertifika uyarısı korelasyonlu ise: Evil Twin şüphesi → yetkili saha inceleme ve iletişim.
Planlı sertifika değişimi ile uyumluysa: yanlış pozitif → profil güncelleme, zincir doğrulama rehberi, izleme tuning.

Rapor özeti (Bulgu → Etki → Öneri → Kanıt)

Bulgu: CorpNet için envanter dışı 02:aa:bb:cc:dd:ee association; sertifika uyarıları ve RADIUS server_cert_untrusted ile korele.
Etki: Yanlış ağa yönlenme, kimlik doğrulama güveninin zedelenmesi, olası veri/oturum riski.
Öneri: İstemci profillerini sıkılaştır; WLC/RADIUS’ta “envanter dışı BSSID + güvenlik tutarsızlığı” alarmını güçlendir; playbook ile saha incelemesi.
Kanıt: Saha listeleri, RADIUS/WLC kesitleri, istemci WLAN logu ve SHA-256 hash’leri.

Terimler Sözlüğü (Glossary)

Terim	Türkçe karşılığı / açıklama
SSID	Kablosuz ağ adı (yayınlanan ağ kimliği)
BSSID	Erişim noktasının MAC kimliği; SSID’nin “hangi cihazdan” yayınlandığını gösterir
Rogue AP	Kurumun izni olmadan kurulan yetkisiz erişim noktası
Evil Twin	Meşru SSID’yi taklit eden sahte yayın (sinyal/kontrol düzeyinde ele alınır)
WLC	Wireless LAN Controller; kurumsal AP’leri merkezi yöneten kontrol sistemi
RADIUS	802.1X gibi kimlik temelli erişimde kullanılan AAA altyapısı
802.1X	Ağ erişim kontrolü için kimlik temelli doğrulama yaklaşımı
AAA	Authentication, Authorization, Accounting; kimlik/yetki/muhasebe üçlüsü
OWE / Enhanced Open	Açık ağlarda opportunistic şifreleme yaklaşımı; “open” ağ riskini azaltmaya yöneliktir
Wi-Fi 7 / 802.11be	IEEE 802.11be eklemeleriyle yeni nesil Wi-Fi kabiliyetleri
Wi-Fi 8 / 802.11bn	Geliştirilmekte olan, güvenilirlik odaklı yaklaşım (UHR vurgusu)
Baseline (Altın liste)	Yetkili SSID/BSSID/politika değerlerinin referans seti

Kendini Değerlendir

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

Bir kullanıcı “CorpNet’e bağlanırken sertifika uyarısı görüyorum” diyor. İlk doğru yaklaşım hangisi?

A) Hemen tüm AP’leri yeniden başlatmak

B) Saha SSID/BSSID/kanal + WLC/RADIUS loglarını aynı zaman penceresinde korele etmek

C) Misafir SSID’yi kapatmak

D) Tüm kullanıcılara Wi-Fi profilini silip yeniden ekletmek

E) Kanal planını rastgele değiştirmek

Doğru: B
Gerekçe: Belirtiyi doğrulamak/çürütmek için çoklu kanıt gerekir. A/C/E “kanıtsız aksiyon”dur; D bazı vakalarda çözebilir ama önce nedenin meşru değişiklik mi şüpheli yayın mı olduğunu ayırt etmez.

Aynı SSID için birden fazla BSSID görülmesi hangi durumda en doğru yorumdur?

A) Her zaman Evil Twin’dir

B) Her zaman Rogue AP’dir

C) Çok AP’li kurumsal tasarımda normal olabilir; kritik olan envanter dışı BSSID ve parametre tutarsızlığıdır

D) 802.1X’in kapalı olduğunu gösterir

E) Misafir izolasyonunun çalışmadığını gösterir

Doğru: C
Gerekçe: Roaming için çok BSSID normaldir. A/B aşırı kesin; D/E doğrudan çıkarım değildir.

Rogue AP ile Evil Twin’i ayırmada en güçlü üçlü kanıt seti hangisi?

A) Tek bir ekran görüntüsü

B) Sadece istemci şikâyeti

C) Saha sinyali + WLC/RADIUS logu + istemci olayları

D) Sadece RF parazit ölçümü

E) Sadece internet yavaşlığı

Doğru: C
Gerekçe: Çoklu kaynak korelasyonu hem doğrulama hem karşı-kanıt için uygundur. Diğerleri tek boyutlu kalır.

Misafir SSID tasarımında “en doğru” güvenlik hedefi hangisidir?

A) Misafirlerin kurumsal yazıcıları görmesi

B) Misafirlerin birbirini görmesi

C) Misafir trafiğinin internete kontrollü çıkması ve iç ağdan ayrıştırılması

D) Misafir SSID’nin kurumsal SSID ile aynı politikayı kullanması

E) Misafirlerde log tutmamak

Doğru: C
Gerekçe: Misafir izolasyonu etki alanını sınırlar. A/B/D riski artırır; E kanıt üretimini zayıflatır.

“Güvenlik olayı sandığımız kopmalar”ın RF kaynaklı olabileceğini en iyi hangi kanıt destekler?

A) RADIUS’ta sertifika hatası artışı

B) WLC’de SSID parametre değişikliği

C) Retry artışı + roam reason + birden fazla SSID’de benzer kopma örüntüsü

D) Tek bir cihazın profilinin bozulması

E) Bir kullanıcı “internet yavaş” demesi

Doğru: C
Gerekçe: RF kaynaklı sorunlar genelde retry/roaming metrikleri ve geniş etki ile görünür. A/B daha çok güvenlik/politika değişikliğini işaret eder; D/E zayıf sinyaldir.

Bir şüphede “karşı-kanıt” aramanın temel amacı nedir?

A) Olayı hızlı kapatmak

B) Hipotezi çürütüp yanlış pozitif aksiyonları azaltmak

C) Daha fazla veri toplamak için gerekçe üretmek

D) Kullanıcıyı suçlamak

E) Saha ekibini devre dışı bırakmak

Doğru: B
Gerekçe: Karşı-kanıt, yanlış yönlendiren belirtileri ayıklar. C her zaman doğru değildir; A/D/E amaç dışıdır.

Kanıt paketlemede en doğru uygulama hangisi?

A) Tüm logları sınırsız süreyle toplamak

B) PCAP/log çıktısını zaman penceresiyle sınırlayıp hash’lemek ve notlandırmak

C) Sadece hash almak, bağlam notu yazmamak

D) Sadece ekran görüntüsü almak

E) Dosyaları düzenleyip “daha anlaşılır” hale getirmek (orijinali saklamadan)

Doğru: B
Gerekçe: Minimum veri + bütünlük + izlenebilirlik esastır. C bağlamı eksik bırakır; D zayıf kanıttır; E bütünlüğü riske atar; A gereksiz risk yükler.

“Envanter dışı BSSID + güvenlik türü tutarsız + sertifika uyarısı” birlikteyse en doğru ilk karar nedir?

A) Kesin saldırı var demek

B) Playbook’a göre yetkili süreçle doğrulama/izolasyon adımlarını başlatmak ve iki bağımsız kaynakla doğrulamak

C) Hiçbir şey yapmamak

D) Kurumsal SSID’yi kalıcı kapatmak

E) Kullanıcılara şifreyi göndermek

Doğru: B
Gerekçe: Üçlü sinyal güçlüdür ama yine de doğrulama gerekir; A aşırı kesin, D aşırı yıkıcı, E hatalı ve risklidir.

OWE/Enhanced Open yaklaşımının en doğru hedefi hangisidir?

A) Kurumsal 802.1X yerine geçmek

B) Açık misafir ağlarında istemci–AP arasındaki bağlantıda opportunistic şifreleme ile riski azaltmak

C) Rogue AP’leri otomatik engellemek

D) RADIUS’u devre dışı bırakmak

E) WLC ihtiyacını ortadan kaldırmak

Doğru: B
Gerekçe: Enhanced Open, açık ağların riskini azaltmaya yöneliktir; kurumsal kimlik modelinin yerine geçmez.

Wi-Fi 8 (802.11bn) için doğru kavramsal vurgu hangisidir?

A) Sadece hız artışı

B) Sadece yeni frekans bandı

C) Güvenilirlik/kararlılık metriklerine odak (UHR vurgusu)

D) Kablosuz güvenliği ortadan kaldırır

E) 802.1X’i gereksiz yapar

Doğru: C
Gerekçe: Ufukta Wi-Fi 8’in anlatılan yönü “reliability” odağıdır; diğer şıklar ya aşırı iddialı ya da bağlam dışıdır.

Bu modülde neler öğrendik?

Kurumsal Wi-Fi’ın kimlik (802.1X), politika, segmentasyon ve operasyon disipliniyle yönetildiğini.
Rogue AP ve Evil Twin risklerini cracking olmadan; sinyal + log + karşı-kanıt yaklaşımıyla ele almayı.
Yeni nesil Wi-Fi kabiliyetlerinin görünürlük ve değişiklik yönetimini neden daha kritik hale getirdiğini.
Windows/Linux/macOS üzerinde güvenli denetim/okuma ile kanıt toplayıp bütünlük (hash) ile paketlemeyi.
Playbook mantığıyla (hazırlık → uygulama → doğrulama → kanıt → rollback) kablosuz şüpheleri operasyonel olarak yönetmeyi.

MODÜL 10 — IoT/OT Network Güvenliği

Kavramsal şema: çok sayıda IoT ucundan gelen risk; güvenli köprü ve sınır; OT sahasında PLC/HMI ve izleme; segmentler arası lateral hareketin sınırlandırılması.

IoT ve OT (Operational Technology) ağları; klasik IT ağlarına göre daha uzun ömürlü, değişime daha hassas ve kesinti maliyeti çok daha yüksek sistemleri taşır. Bu yüzden OT güvenliği “daha fazla ajan/araç kurmak”tan önce segmentasyon disiplini, akışların açık tanımı (kim→kime→ne için) ve kanıt üretilebilir görünürlük üzerine kurulur. Modül boyunca IT–OT farkının risk profilini nasıl dönüştürdüğünü; Zone–Conduit (bölge–hat) yaklaşımıyla OT segmentasyonunu nasıl tasarlayıp doğrulayacağını; OT’de “gürültüsüz, yüksek doğruluklu tespit sinyali” üretmenin ne demek olduğunu ele alacaksın. Ayrıca MITRE ATT&CK for ICS’i ezberlenecek isimler listesi değil, teknik → sinyal → kontrol eşlemesi için “ortak dil” olarak konumlandıracaksın. Son olarak IoT bağlantı trendlerinde eSIM/uzaktan profil yönetimi (GSMA SGP.32 farkındalığı) boyutunun; ağ envanteri, erişim güvenliği ve “görünmez egress” riskini nasıl etkilediğini operasyonel bakışla çerçeveleyeceksin.

Bu Dersin Hedefleri

IT ve OT ağları arasındaki farkları risk profili (kesinti, safety, yama ritmi, görünürlük) üzerinden yorumlamak.
Zone–Conduit yaklaşımıyla OT segmentasyonunu akış mantığına dayandırmak ve “hangi akış neden var?” sorusunu kurumsal dile çevirmek.
OT ortamında tespit için pasif/düşük riskli veri kaynaklarını seçmek ve kanıt standardında çıktı üretmek.
MITRE ATT&CK for ICS’i “ortak dil” olarak kullanıp teknik → sinyal → kontrol eşlemesi kurmak.
IoT’de eSIM yaşam döngüsünün (profil/abonelik yönetimi) ağ envanteri ve erişim güvenliğine etkisini kavramak (SGP.32 farkındalığı).
Zone–Conduit Akış Matrisi ile OT segmentasyonunu doğrulayan HOW-TO’yu uçtan uca uygulamak (hazırlık→uygulama→doğrulama→kanıt→rollback).

Ana içerik

10.1 IT vs OT farkı, risk profili

IT ağları çoğunlukla bilgi sistemlerini (kullanıcı uçları, sunucular, kurumsal uygulamalar) taşır. OT ağları ise fiziksel süreçleri yöneten sistemlere (PLC’ler, sensör/aktüatörler, operatör istasyonları, endüstriyel ağ bileşenleri) hizmet eder. OT’de güvenlik hedefi yalnızca gizlilik değil; süreklilik (availability) ve çoğu senaryoda safety ile birlikte düşünülür. Bu yüzden OT’de “güvenli ama gürültülü” hamleler (kontrolsüz doğrulama, agresif test) ters tepebilir; en doğru yol çoğu zaman önce görünürlük/kanıt, sonra değişikliktir.

IT

Bilgi ve iş uygulamaları; daha hızlı değişim ve yama döngüsü.

OT

Fiziksel süreç; süreklilik, safety ve düşük değişim riski öncelidir.

Etki / risk (operasyonel sonuç)

Kesinti maliyeti OT’de çok yüksektir: küçük bir ağ hatası üretim kaybı veya fiziksel etki doğurabilir.
Yama/upgrade döngüsü yavaştır; legacy bileşenler yaygındır. “Mükemmel konfig” yerine koruyucu mimari (segmentasyon, dar akışlar, değişiklik disiplini) kritik hale gelir.
En pahalı hata: IT refleksiyle OT’ye müdahale edip kanıtsız/acele izolasyon yapmak (yanlış pozitif → operasyon zararı).

Tespit sinyali / kanıt

OT varlıklarının konuşma örüntüsü genellikle sabittir: “dün böyleydi, bugün niye değişti?” sorusu güçlü sinyal üretir.
Kanıt kaynakları (tercihen pasif/düşük riskli): FW/ACL logları, switch port/VLAN olayları, OT gateway logları, erişim geçidi (jump server) kayıtları, PCAP/flow benzeri özetler.

Savunma kontrolü / düzeltme yaklaşımı

IT ↔ OT arasına tampon bölge/DMZ ve kontrollü geçişler koy; kontrolsüz iletişimi kır.
Değişiklikleri kayıt altına al: “hangi akış ne zaman, kim tarafından, hangi gerekçeyle açıldı?” cevaplanabilir olmalı.

Dikkat: OT’de “müdahale”ye geçmeden önce “kanıt seti”ni seçmek, yanlış pozitif maliyetini dramatik biçimde düşürür.

10.2 Zone–Conduit yaklaşımı

Zone–Conduit yaklaşımı, OT ağını “tek parça LAN” yerine güvenlik bölgeleri (zone) ve bu bölgeler arasındaki tanımlı iletişim hatları (conduit) olarak tasarlamayı hedefler. Zone, benzer risk/işlev profiline sahip varlıkları gruplar (ör. kritik kontrol, operasyon, izleme, üçüncü taraf erişim). Conduit ise iki zone arasında yalnızca gerekli akışların geçtiği “tekil/denetlenebilir geçiş yolu”dur: kim → kime → ne amaçla → hangi servis sınıfıyla → hangi zaman penceresinde. (Bu yaklaşım, OT güvenliğinde yaygın standart/pratiklerde “bölgeleme + kontrollü geçiş” fikrinin merkezindedir.)

Etki / risk

Zone yoksa yayılma etkisi büyür: bir uçtaki zayıflık başka bölgelere sıçrar.
Conduit tanımsızsa FW/ACL politikası “kural yığını”na dönüşür; denetim ve olay anında karar vermek zorlaşır.
“Default allow” kültürü OT’de sessiz risk üretir; çünkü birçok OT protokolü doğası gereği “kim gönderdi?” ayrımını iyi yapmaz (bu, savunma tarafında ağı davranışla yönetmeyi daha kritik hale getirir).

Tespit sinyali / kanıt

Conduit dışı iletişim girişimleri: beklenmeyen kaynak–hedef çifti, beklenmeyen zaman penceresi, beklenmeyen yön (OT’den IT’ye doğru yeni egress).
Kanıt: FW deny log artışı, OT gateway “policy violation” olayları, switch üzerinde beklenmeyen VLAN/port hareketi.

Savunma kontrolü / düzeltme yaklaşımı

Zone’ları işlev + kritikilik üzerinden tanımla; sonra her conduit için Akış Matrisi üret: “izinli olanları yaz; yazmadığını varsayılan olarak yasakla.”
Denetim hedefi: Her izin “iş gerekçesi” ve “kanıt kaynağı” ile beraber yaşamalı.

İpucu: Akış matrisi olmadan yapılan segmentasyon “güvenlik”ten çok “karmaşıklık” üretir. Matrisi önce küçük tut; olgunlaştıkça genişlet.

10.3 Tespit sinyalleri

OT’de iyi tespit sinyali; yüksek doğrulukla beklenen davranıştan sapmayı yakalayan, mümkünse pasif ve düşük riskli ölçümlerle elde edilen sinyaldir. Amaç “her şeyi görmek” değil; triage’a yarayacak az ama değerli veri üretmektir.

Etki / risk

Aşırı veri toplama OT’de hem performans riskini hem analiz yükünü artırır.
Düşük kaliteli sinyal, gereksiz müdahale doğurur (özellikle kesinti maliyeti yüksek ortamlarda).

Tespit sinyali / kanıt (örnek sınıflar)

Zaman sapması: Normalde gece konuşmayan bir cihazın gece iletişim kurması.
Yön sapması: Normalde sadece içe konuşan bir segmentin dışa konuşması (yeni egress).
Rol sapması: “Sadece izleme” zonundaki bir bileşenin kontrol zonuna doğru oturum başlatması.
Kimlik sapması: Yeni/alışılmadık MAC/OUI sınıfı, yeni switch portunda görünme vb.
Protokol davranış sapması: “Okuma/telemetri” ağırlıklı olması beklenen bir akışta yazma/komut sınıfı işlemlerin artması. (Buradaki amaç saldırıyı öğretmek değil; savunma için “neye bakarım?” çerçevesidir.)

Savunma kontrolü / düzeltme yaklaşımı

Baseline üret: “normal akış = normal kanıt”.
Sinyali tek kaynaktan hükme bağlama; karşı kanıt ara: “planlı bakım mı, yanlış konfig mi, gerçek anomali mi?”
Alarmı “tek paket”le değil; zaman korelasyonu + conduit politikası + varlık rolü ile güçlendir.

BYPASS / erişim farkındalığı (sınır içinde)

Alan	Açıklama
Kategori	Segmentasyon boşluğu
Amaç	Saldırgan, düşük kritik zon üzerinden daha kritik zona erişim arar (kavramsal)
Beklenen iz / sinyal	Conduit dışı yeni akış denemeleri, beklenmeyen yön değişimi
Savunma kontrolü	Akış matrisi + default deny + korelasyonlu alarm
Kanıt örneği (uydurma)	`action=DENY src=192.0.2.40 dst=192.0.2.10 reason=conduit_violation`

10.4 Referans çerçeveler (MITRE ATT&CK for ICS)

MITRE ATT&CK for ICS, ICS/OT bağlamındaki teknikleri bir bilgi tabanı olarak sunar. Değeri “isim ezberi” değil; teknik → olası gözlem → uygun kontrol eşlemesini ortak dile dönüştürmesidir. Böylece SOC/CSIRT, OT ekibi ve yönetim aynı cümleyi konuşabilir: “Bu teknik sınıfında hangi sinyali nerede arıyoruz?”

Etki / risk

Ortak dil yoksa olay toplantıları “varsayım savaşı”na döner.
Çerçeveyi yanlış kullanmak “her şeyi engelleyelim” gibi gerçekçi olmayan hedefler doğurur.

Tespit sinyali / kanıt

ATT&CK for ICS’i “alarm üreteci” değil; kayıt kaynaklarını seçme, korelasyon sorularını netleştirme aracı olarak kullan.

Örnek konumlandırma

Inhibit Response Function

Komutların engellenmesi/bloklanması gibi davranışlar (ör. “Block Command Message”) operatörün yanıt verme kabiliyetini etkileyebilir; savunmacı bunu ağ/OT kontrol kanıtları ile ilişkilendirir.

Impair Process Control

Süreç kontrolünü bozacak davranışlar (ör. “Manipulation of Control”) fiziksel sürece etki riski taşır; savunmacı bunu rol sapması + komut sınıfı artışı + conduit ihlali ile birlikte okur.

Savunma kontrolü / düzeltme yaklaşımı

Her kritik zone için “3 satırlık pratik eşleme” yap:

En kritik varlık/işlev
Bu işlev için en kritik sapma sınıfları
Bu sapmalar için kanıt kaynağı + kontrol

Bu, çerçeveyi uygulanabilir bir “sinyal haritası”na dönüştürür.

10.5 IoT bağlantı trendi: eSIM yönetimi (GSMA SGP.32 farkındalığı)

IoT’de cihazların hücresel bağlantısı artarken, eSIM ile uzaktan profil/abonelik yönetimi daha kritik hale gelir. Buradaki güvenlik konusu “SIM tak–çıkar” değil; cihaz filosu için kimlik, yetkilendirme, tedarik zinciri ve yaşam döngüsü yönetimidir. SGP.32, IoT eSIM ekosisteminde uzaktan yönetimi daha ölçeklenebilir kılmayı hedefleyen bir yaklaşım olarak konumlandırılır; pratikte bu, “cihaz kimliği + profil yönetimi + ağ çıkışı” üçlüsünün envanter ve denetim süreçlerine daha sıkı bağlanması gerektiği anlamına gelir.

Risk

Envanter ve yaşam döngüsü; görünmez egress.

Yaklaşım

Gateway’i zone’a al; conduit ve logları netleştir.

Etki / risk

Envanter körlüğü: Hücresel çıkışı olan bir IoT gateway, “ağ dışı” bir yol oluşturabilir. Bu yolun politikası ve logları net değilse risk büyür.
Yaşam döngüsü riski: Profil değişimi/taşıma süreçleri zayıf yönetilirse cihaz kimliği ve bağlantı kontrolü zayıflar; “kim, ne zaman, hangi profili aldı?” sorusu cevapsız kalır.

Tespit sinyali / kanıt

Beklenmeyen hücresel egress: OT zone’dan hücresel gateway’e doğru yeni/alışılmadık akışlar.
Cihaz yönetim kayıtlarında beklenmeyen profil/abonelik olayı (kurumda bu kayıtlar tutuluyorsa).
Router/FW tarafında beklenmeyen uplink davranışı (özellikle plan dışı zamanlarda).

Savunma kontrolü / düzeltme yaklaşımı

Hücresel çıkışı “görünmez internet” gibi bırakma: gateway’i ayrı bir zone’a al, izinli conduit’leri tanımla, log kaynağını netleştir.
eSIM yönetimini “telekom detayı” değil; varlık yönetimi + erişim kontrolü bileşeni olarak ele al.

Dikkat: Bu modülde eSIM konusu farkındalık düzeyindedir: hedef, OT segmentasyon ve kanıt disiplininde “hücresel yol”u unutmayacak refleksi kazandırmaktır.

10.6 HOW-TO: Zone–Conduit Akış Matrisi ile OT Segmentasyonu Doğrulama

Aşağıdaki playbook, yalnızca izinli/kurum içi yetkili ortam veya tamamen yerel lab varsayımıyla; kesinti riski yaratmadan segmentasyonu doğrulamak ve kanıt üretmek içindir.

1HazırlıkZone · conduit · matris · do-not-harm

2UygulamaGerçek trafik · matris · conduit

3DoğrulamaÇapraz kanıt · tekil test

4KanıtPaketleme · hash · rapor

5RollbackTuning · güvenli daraltma

Aşama 1 — Hazırlık

1.1 Zone envanteri (minimum)

Zone adı, işlevi, kritikliği
Zone’daki varlık sınıfları (kontrol/izleme/operasyon/3. taraf vb.)
Zone giriş/çıkış noktaları (FW/ACL, router, gateway)

1.2 Conduit envanteri

Conduit adı (ör. Z-Operasyon → Z-Kontrol)
Uygulanan kontrol (FW politika adı / ACL adı / kural seti referansı)
Log kaynağı: deny/allow kanıtı nerede?

1.3 Akış Matrisi şablonu (çekirdek artefakt)

Kaynak Zone	Hedef Zone	İzinli mi?	Amaç (iş gerekçesi)	Servis sınıfı	Zaman penceresi	Kanıt kaynağı
Z-Operasyon	Z-Kontrol	Evet	SCADA telemetri senkronu	telemetri	7×24	FW / SIEM
…	…	Evet/Hayır	…	ör. telemetri	ör. vardiya	FW / SIEM

1.4 Do-not-harm doğrulama planı

Aktif test gerekiyorsa: tek hedef + tek servis + kısa süre
Üretimde kapsam büyütme yok; mümkünse bakım penceresi
“Görünürlük yoksa kanıt yoktur” ilkesini baştan kabul et

Servis sınıfı: Port/protokol numarası yazmak zorunda değilsin; “telemetri”, “operatör görüntüleme”, “yönetim” gibi sınıflar yeterli olabilir. Denetimde gerekiyorsa “tekil hedef/tekil servis” seviyesine indir.

Aşama 2 — Uygulama

2.1 “Mevcut gerçek”i çıkar (gözlem)

FW/ACL politika export’u (salt okuma)
Son 24 saat allow/deny özetleri (salt okuma)
Gerekliyse kısa PCAP dilimi (pasif) + Conversations/Endpoints özeti

2.2 Matrisi doldur (tasarım → gerçek)

Her “izin” için iş gerekçesi yaz
“Gerekçesi olmayan izin”i kırmızı işaretle (aday daraltma)

2.3 Conduit bazlı kontrol doğrulaması

“Kural var mı?” + “log üretiyor mu?”
Log yoksa “engel var” diye varsayma: önce görünürlük açığıdır.

Aşama 3 — Doğrulama (kanıt odaklı)

3.1 Bu belirtiyi ne doğrular, ne çürütür? (karşı kanıt disiplini)

“Conduit dışı akış var” iddiası için iki bağımsız kanıt hedefle:

FW/ACL log kesiti (zaman pencereli)
PCAP/flow özeti veya switch port olayı

3.2 Güvenli tekil doğrulama (gerekirse)

Matriste “izinli” olan tek bir akış için tekil doğrulama yap:

Başarısızlıkta hemen “policy bozuk” deme; servis down olabilir → karşı kanıt ara.

Aşama 4 — Kanıt paketleme

4.1 Kanıt seti (minimum)

Akış matrisi (CSV/XLSX/PDF)
FW/ACL kural export’u (salt okuma)
Log kesitleri (zaman penceresi net)
PCAP + Conversations/Endpoints export’u (varsa)
Hash listesi (SHA-256)
“Kim/Ne zaman/Nerede/Neden aldı?” kısa notu

4.2 Rapor iskeleti (Bulgu → Etki → Öneri → Kanıt)

Bulgu: Matriste tanımsız akış / Conduit log üretmiyor / gerekçesiz izin
Etki: Yayılma, görünürlük kaybı, uyumluluk ve operasyon riski
Öneri: Kural daraltma, logging ekleme, conduit yeniden tanımı, değişiklik disiplini
Kanıt: Hash’li dosyalar + log/özet tablolar

Aşama 5 — Geri dönüş / rollback

Yanlış pozitif çıkarsa: matriste istisnayı gerekçelendir, baseline’ı güncelle, alarm koşullarını tuning et.
Gerçek uygunsuzluksa: değişiklik yönetimi ile kural daralt; OT’de çoğu zaman “önce logging, sonra daraltma” daha güvenlidir.

Dikkat: OT’de “anında kapat” refleksi her zaman doğru değildir. Kanıtın kalitesi ve kesinti riski kararın parçasıdır.

10.7 Komut & Araç Okuryazarlığı (Windows / Linux / macOS + Wireshark)

Aşağıdaki komutlar yalnızca denetim/okuma, güvenli tekil doğrulama, kanıt üretimi içindir. OT’de mümkünse üretim yerine izinli lab/benzetim kullan; üretimdeyse SPAN/TAP gibi pasif kopya üzerinden ilerle.

Hızlı komut seti (özet)

Görev	Windows (PowerShell)	Linux	macOS
Ağ / rota özeti	`Get-NetIPConfiguration`; `Get-NetRoute`	`ip addr`; `ip route`	`ifconfig`; `netstat -rn`
Bağlantı / komşu	`Get-NetTCPConnection`; `arp -a`	`ss -tuna`; `ip neigh`	`netstat` / `arp` (gerektiğinde)
Kısa PCAP	— (tercihen ayrı istasyon)	`tcpdump`	`tcpdump`
Bütünlük	`Get-FileHash`	`sha256sum`	`shasum -a 256`
Tekil doğrulama	`Test-NetConnection`	`nc -zv`	`nc -zv`

Windows (PowerShell)

1. Ağ konfigürasyonunu kanıta almak (okuma/kanıt)

Kanıt klasörü + IP

PS C:\evidence> New-Item -ItemType Directory -Force .\evidence | Out-Null; Get-NetIPConfiguration | Format-List | Out-File .\evidence\net_ipconfig.txt -Encoding UTF8

Amaç: IP/DNS/Gateway gerçekliğini olay anında sabitlemek
Yorum ipucu: InterfaceAlias, IPv4DefaultGateway, DNSServer alanları
Güvenli sınır: Yerel okuma

2. Rota tablosunu almak (okuma/kanıt)

Get-NetRoute

PS C:\evidence> Get-NetRoute | Sort-Object DestinationPrefix | Out-File .\evidence\net_routes.txt -Encoding UTF8

Amaç: Beklenmeyen yönlendirme/varsayılan rota değişimini görmek
Yorum ipucu: 0.0.0.0/0 benzeri varsayılan rota, Metric değişimleri
Güvenli sınır: Yerel okuma

3. Uç bağlantı özetini almak (okuma/kanıt)

Get-NetTCPConnection

PS C:\evidence> Get-NetTCPConnection | Select-Object State,LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess | Out-File .\evidence\net_tcpconnections.txt -Encoding UTF8

Amaç: “Kim kiminle konuşuyor?” sorusuna süreç ilişkilendirmeli özet
Yorum ipucu: Beklenmeyen RemoteAddress/RemotePort çiftleri (akış matrisiyle karşılaştır)
Güvenli sınır: Yerel okuma

4. ARP / komşu tablosu (okuma/kanıt)

ARP tablosu

PS C:\evidence> arp -a > .\evidence\net_arp.txt

Amaç: Aynı L2 segmentte görülen IP↔MAC eşleşmelerini kanıtlamak
Yorum ipucu: Yeni/alışılmadık MAC üreticisi/OUI izleri
Güvenli sınır: Yerel okuma

5. Kanıt bütünlüğü (hash)

SHA-256

PS C:\evidence> Get-FileHash .\evidence\* -Algorithm SHA256 | Out-File .\evidence\evidence_hashes.sha256.txt -Encoding UTF8

Amaç: Kanıt setinin bütünlüğünü göstermek
Güvenli sınır: Yerel

6. Tekil servis doğrulaması (güvenli doğrulama)

Tek hedef / tek port

PS C:\evidence> Test-NetConnection -ComputerName 192.0.2.10 -Port 443

Amaç: Akış matrisi “izinli” dediği tek bir servisin erişimini doğrulamak
Yorum ipucu: False ise “policy mi, servis mi?” için karşı kanıt ara
Güvenli sınır: Tek hedef, tek port; tarama değil

Linux

1. Arayüz/IP ve rota (okuma/kanıt)

ip — adres ve rota

analist@ot:~/evidence$ mkdir -p ./evidence; ip addr show > ./evidence/ip_addr.txt; ip route show > ./evidence/ip_route.txt

Amaç: Cihazın hangi ağda olduğunu ve rotasını sabitlemek
Yorum ipucu: Varsayılan rota, beklenmeyen ikinci rota
Güvenli sınır: Yerel okuma

2. Komşu (ARP) tablosu

ip neigh

analist@ot:~/evidence$ ip neigh show > ./evidence/ip_neigh.txt

Amaç: Aynı L2’de görülen komşuları kanıtlamak
Yorum ipucu: Yeni MAC’ler, sık “FAILED/INCOMPLETE” (L2 sorunları)
Güvenli sınır: Yerel okuma

3. Soket/bağlantı özeti

ss -tuna

analist@ot:~/evidence$ ss -tuna > ./evidence/ss_tuna.txt

Amaç: İçerik toplamadan “uçlar ve portlar” düzeyinde görünürlük
Güvenli sınır: Yerel okuma

4. Kısa süreli trafik yakalama (kanıt) — tercihen SPAN/TAP

tcpdump — kısa dilim

analist@ot:~/evidence$ sudo tcpdump -i eth0 -w ./evidence/ot_slice.pcap -G 60 -W 1 -s 96

Amaç: Kısa süre/sınırlı paket boyu ile “kanıt dilimi”
Güvenli sınır: Üretimde dar pencere; do-not-harm

5. Kanıt paketleme + hash

Hash + arşiv

analist@ot:~/evidence$ sha256sum ./evidence/* > ./evidence/evidence_hashes.sha256; tar -czf evidence_bundle.tar.gz ./evidence

Amaç: Kanıt setini bütünlükle paketlemek
Güvenli sınır: Yerel

macOS

1. Ağ arayüzleri ve rota

ifconfig / netstat

analist@MacBook evidence % mkdir -p ./evidence; ifconfig > ./evidence/ifconfig.txt; netstat -rn > ./evidence/routes.txt

Amaç: Olay anındaki arayüz ve rota gerçekliğini kaydetmek
Güvenli sınır: Yerel okuma

2. Kısa süreli PCAP

tcpdump

analist@MacBook evidence % sudo tcpdump -i en0 -w ./evidence/ot_slice.pcap -G 60 -W 1 -s 96

Amaç: Sınırlı süre ile kanıt dilimi
Güvenli sınır: Do-not-harm

3. Hash

shasum

analist@MacBook evidence % shasum -a 256 ./evidence/* > ./evidence/evidence_hashes.sha256

Güvenli sınır: Yerel

Wireshark okuryazarlığı (OT için güvenli okuma)

Üretim OT segmentinde mümkünse SPAN/TAP ile pasif kopya al; capture süresini kısa tut; içerikten önce uçlar, zamanlama, hacim ve yön gibi meta davranışlara odaklan.

Nasıl okurum? (ekranlar + filtre)

İlk daraltma: ip.addr == 192.0.2.10 gibi uç bazlı filtre; sonra konuşmaları çıkar.
Statistics → Conversations / Endpoints: Zone–Conduit matrisiyle karşılaştırılacak en hızlı özet.
Expert Information: yeniden deneme, sıra dışı reset/timeout gibi yan sinyaller.
OT protokolleri için (ortama göre) ilgili çözümleyici/alanlara odaklan: ör. Modbus TCP, S7comm vb.
Savunma odaklı okuma: “Beklenen akışta komut/yazma sınıfı işlemler artmış mı?”
Modbus örneği: Function Code alanı; okuma sınıfı (örn. 01) ile yazma sınıfı (örn. 05, 0F) ayrımı “rol sapması” için sinyal üretebilir.

Nasıl kanıta çeviririm?

Conversations tablosunu CSV dışa aktar + ekran görüntüsü + kısa not: “Bu akış matriste var mı?”
PCAP + özet CSV + hash → raporda “Kanıt” bölümünün çekirdeği.

10.8 Operasyonel Senaryo (ileri seviye — izinli/uydurma)

Senaryo uydurma verilerle örneklendirilmiştir; amaç suç atfetmek değil, kanıt zinciriyle doğru hipotezi bulmaktır.

Belirti

Z-Operasyon zonundaki bir IoT gateway’de plan dışı uplink; aynı pencerede Z-Kontrol ile ilişkili kısa anomali; operatör ekranında açıklayan net operasyon kaydı yok.

Toplanacak kanıt (minimum)

Akış Matrisi + FW/ACL export
Son 2 saat allow/deny (Z-Operasyon ↔ Z-Kontrol, egress)
Kısa PCAP + Conversations export
Gateway yerel ağ kanıtı + hash
Değişiklik kayıtları

Hipotez tablosu

#	Hipotez	Not
1	Planlı değişiklik	Yeni sensör; gateway profili güncellendi (meşru).
2	Segmentasyon boşluğu	Yanlış zone veya geniş conduit.
3	Envanter sapması	eSIM/bağlantı değişti; envanter güncellenmedi.
4	Yanlış pozitif	Korelasyon/zaman eşlemesi hatası.

Uydurma kanıt kesitleri (örnek)

FW log

Örnek

2026-02-10T10:12:11Z action=DENY src=192.0.2.40 dst=192.0.2.10 reason=conduit_violation conduit=Z-Operasyon_to_Z-Kontrol

PCAP / Conversations özeti

192.0.2.40 → 192.0.2.10 (3 deneme, kısa aralık)
192.0.2.40 → 198.51.100.20 (yeni egress, periyodik)

Değişiklik kaydı

10:00–10:30 planlı devreye alma: yok

Analiz adımları

Zaman korelasyonu: deny log ↔ PCAP ↔ değişiklik kaydı.
Akış matrisi: Z-Operasyon → Z-Kontrol conduit’inde 192.0.2.40 için izinli akış var mı?
Zone doğrulaması: Gateway doğru zone’da mı? (VLAN/rota/arayüz)
Conduit görünürlüğü: Log üretiyor mu? Üretmiyorsa önce görünürlük açığı.
Egress: Yeni uplink eSIM/konfig ile uyumlu mu? (ağ + envanter)

Karar

Planlı değişiklik + matriste tanımlı akış + kanıt tutarlıysa: siber olay değil; iletişim/change eksikliği.
Tanımsız akış + conduit violation + change yoksa: segmentasyon uygunsuzluğu → daraltma, değişiklik yönetimi.
Yeni egress + envanter körlüğü: gateway’i ayrı zone; egress’i kontrollü conduit.

Rapor özeti (Bulgu → Etki → Öneri → Kanıt)

Bulgu: 192.0.2.40 için matriste tanımsız denemeler; conduit violation; plan dışı egress.
Etki: Yayılma riski; yanlış zone/akış kesinti ve safety; görünmez egress.
Öneri: Matris güncelle; default deny; conduit logging; hücresel gateway’leri ayrı zone.
Kanıt: FW kesiti, Conversations export, ağ kanıt dosyaları, SHA-256.

Terimler Sözlüğü (Glossary)

Terim	Türkçe karşılığı / açıklama
IT	Kurumsal bilgi sistemleri ağı (veri/iş uygulamaları odaklı)
OT	Fiziksel süreçleri yöneten ağ ve sistemler (süreklilik + safety etkili)
ICS	Endüstriyel Kontrol Sistemleri (SCADA/DCS/PLC vb. genel şemsiye)
PLC	Programlanabilir mantıksal denetleyici (süreç kontrol bileşeni)
Zone	Benzer risk/işlev profiline sahip güvenlik bölgesi
Conduit	İki zone arasındaki tanımlı ve denetlenen iletişim hattı
Baseline	Normal davranışın referans seti (sapma tespiti için)
East–West	Aynı ortam içinde yatay (iç) trafik yönü
Jump server	Kontrollü erişim için ara geçit (kayıt/denetim kolaylaştırır)
Kanıt zinciri	Kanıtın kim-ne zaman-nerede-nasıl alındığı + bütünlük (hash) disiplinidir
MITRE ATT&CK for ICS	ICS odaklı teknik bilgi tabanı; “teknik → sinyal → kontrol” eşlemesi için ortak dil
Inhibit Response Function	Operatör/yanıt fonksiyonunu engellemeye dönük taktik sınıfı
Impair Process Control	Süreç kontrolünü bozma/etkilemeye dönük taktik sınıfı
eSIM	Gömülü SIM; uzaktan profil/abonelik yönetimiyle IoT bağlantısını kolaylaştırır
GSMA SGP.32 (farkındalık)	IoT eSIM uzaktan yönetiminde ölçeklenebilirlik yaklaşımı; ağ envanteri/egress görünürlüğüyle birlikte ele alınmalıdır

Kendini Değerlendir

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

OT ağlarında “do-not-harm” yaklaşımının en doğru gerekçesi hangisidir?

A) OT protokolleri her zaman şifreli olduğu için pasif izleme gereksizdir

B) OT’de kesinti maliyeti düşük olduğu için hızlı değişiklik yapmak daha iyidir

C) OT’de performans/güvenilirlik/safety gereksinimleri nedeniyle agresif doğrulamalar operasyon riski doğurabilir

D) IT’de log tutulmadığı için OT’de de tutulmamalıdır

E) Zone–Conduit sadece IT ağları için tasarlanmıştır

Doğru: C
Gerekçe: OT bağlamında güvenlik kararları süreklilik ve safety ile birlikte değerlendirilir; agresif testler yanlış pozitif ve kesinti riski doğurabilir.

Zone–Conduit yaklaşımında “Conduit” kavramının en iyi tanımı hangisidir?

A) Aynı VLAN içindeki tüm cihazların oluşturduğu ağ parçası

B) İki zone arasında yalnızca gerekli akışların geçtiği, denetlenen geçiş yolu

C) İnternete çıkış yapan her cihazın ayrı bir IP alması

D) Sadece kablosuz istemcilerin bağlandığı segment

E) Trafiği şifreleyen protokol katmanı

Doğru: B
Gerekçe: Conduit, zone’lar arası iletişimi kontrollü ve kanıtlanabilir hale getirir; “kural yığını” yerine akış mantığı kurar.

Aşağıdakilerden hangisi OT’de “yüksek değerli tespit sinyali” yaklaşımıyla en uyumludur?

A) Her cihazda sürekli tam paket yakalama (sınırsız süre)

B) Baseline üretip sapmaları düşük riskli/pasif kanıtlarla doğrulamak

C) Sadece tek bir log kaynağıyla hüküm vermek

D) Tüm zone’lar arası trafiği default allow yapmak

E) Log tutmayı kapatıp yalnızca operatör beyanına güvenmek

Doğru: B
Gerekçe: OT’de amaç “çok veri” değil “doğru sinyal”dir; baseline + karşı kanıt disipliniyle doğruluk artar.

“Conduit dışı akış var” iddiasında en güçlü doğrulama yaklaşımı hangisidir?

A) Sadece PCAP görmeden “kesin saldırı” demek

B) Sadece FW deny sayacına bakıp karara varmak

C) İki bağımsız kanıtla (FW/ACL log + PCAP/flow/switch olayı) zaman korelasyonu kurmak

D) Akış matrisi olmadan hızlıca tüm trafiği kapatmak

E) Sadece cihazın arayüz çıktısını almak

Doğru: C
Gerekçe: Karşı kanıt disiplini ve iki bağımsız kaynak, yanlış pozitif riskini azaltır.

MITRE ATT&CK for ICS’in bu modüldeki en doğru kullanımı hangisidir?

A) Teknikleri ezberleyip her birini tek tek engellemeye çalışmak

B) Alarm üretmek için tek başına yeterli bir kural motoru olarak kullanmak

C) “Teknik → sinyal → kontrol” eşlemesi için ortak dil ve sinyal haritası oluşturmak

D) Sadece fiziksel güvenlik prosedürleri yazmak

E) Sadece Wi-Fi tehditlerini sınıflandırmak

Doğru: C
Gerekçe: Çerçeve, paydaşlar arası ortak dil kurar ve gözlem/kontrol eşlemesini sistematikleştirir.

eSIM/eğress bağlamında “envanter körlüğü” en çok hangi riskle ilişkilidir?

A) DNS cache zehirlenmesi

B) Görünmez hücresel uplink üzerinden politikasız/logsuz çıkış oluşması

C) VLAN trunking hatası

D) Sadece kablolu portların kapatılması

E) TLS sertifika süresinin dolması

Doğru: B
Gerekçe: Hücresel çıkış, “ağ dışı yol” doğurabilir; envanter ve görünürlük zayıfsa denetim ve olay müdahalesi zorlaşır.

Aşağıdaki seçeneklerden hangisi “güvenli tekil doğrulama” ilkesine en uygundur?

A) Geniş aralıkta port taraması yapmak

B) Tek hedef + tek servis için kısa süreli bağlantı testi yapmak

C) Tüm zone’ları birbirine açıp “sorun var mı?” bakmak

D) Üretimde uzun süreli tam paket yakalama başlatmak

E) Loglamayı kapatmak

Doğru: B
Gerekçe: Do-not-harm kapsamında doğrulama, kapsamı dar ve kontrollü olmalıdır.

“Log yoksa kanıt yoktur” ifadesi en çok hangi durumu anlatır?

A) Log yoksa mutlaka saldırı yoktur

B) Log yoksa mutlaka her şey engellenmiştir

C) Görünürlük yoksa “engel/izin” hakkında kesin hüküm vermek risklidir

D) PCAP her zaman logdan daha kötüdür

E) Akış matrisi gereksizdir

Doğru: C
Gerekçe: Kayıt/kanıt üretmeyen kontrol, denetimde ve olay anında belirsizlik üretir.

Rollback/geri dönüş kararında OT bağlamında en kritik denge hangisidir?

A) Estetik kablolama vs maliyet

B) Kanıt kalitesi vs kesinti/safety riski

C) Wi-Fi hızları vs kapsama

D) Kullanıcı parolası vs ekran parlaklığı

E) Proxy türü vs tarayıcı sürümü

Doğru: B
Gerekçe: OT’de “anında kapat” her zaman doğru değildir; karar kanıt ve operasyon riskiyle birlikte verilir.

Aşağıdakilerden hangisi iyi tasarlanmış bir Akış Matrisi’nin olmazsa olmazıdır?

A) Her satırda mutlaka gerçek IP adresleri yazmak

B) Her izni bir iş gerekçesi ve kanıt kaynağıyla ilişkilendirmek

C) Default allow yaklaşımını temel almak

D) Log kaynaklarını gizli tutmak

E) Zaman penceresini hiç belirtmemek

Doğru: B
Gerekçe: Akış matrisi “izinlerin gerekçesi”ni ve “kanıt üretimini” birlikte taşır; denetim ve triage hızlanır.

Kapanış: Bu modülde neler öğrendik?

OT güvenliğinin IT’den farklı olarak kesinti ve safety maliyeti yüksek bir risk profiline sahip olduğunu.
Zone–Conduit yaklaşımıyla segmentasyonun “kural yığını” değil, akış matrisi ile yönetilen mimari disiplin olduğunu.
OT’de tespit sinyalinin; pasif, düşük riskli ve karşı kanıt disiplinine dayalı seçilmesi gerektiğini.
MITRE ATT&CK for ICS’in “teknik → sinyal → kontrol” eşlemesiyle ortak dil kurmak için kullanılacağını.
IoT’de eSIM/SGP.32 farkındalığının; envanter, zone tasarımı ve egress görünürlüğüyle birlikte ele alınması gerektiğini.
Zone–Conduit Akış Matrisi ile OT segmentasyonunu doğrulamayı; kanıt paketleme + rollback dahil uçtan uca yürütmeyi.

MODÜL 11 — Network Olayları, Müdahale Mantığı ve Kayıt Disiplini

Kavramsal şema: tespitten triage ve kısıtlamaya giden müdahale hattı; kanıt ve kapatma; altta bilet, değişiklik kaydı ve kanıt paketiyle tutarlı kayıt disiplini.

Ağ güvenliğinde “alarm gördüm” ile “kanıt standardında karar verdim” arasındaki farkı kapatan şey; doğru triage, doğru kayıt ve doğru iletişim disiplinidir. Bu modülde odak; olayları hızlı ama temkinli sınıflandırmak, panik anında “en az riskli/doğru” ilk aksiyonları seçmek, delilleri karartmadan (forensic soundness) ilerlemek ve SOC/CSIRT zincirine doğru paketle veri aktarmaktır. Bir olayda en pahalı hata; kanıtsız ve geniş kapsamlı izolasyonla hizmet kesintisi üretmek ya da eksik kayıt nedeniyle olayı “çözdük sandırıp” tekrar yaşatmaktır. Bu yüzden modül; karşı kanıt arama refleksini, gözlem–yorum ayrımını, zaman çizelgesi tutarlılığını ve “Bulgu → Etki → Öneri → Kanıt (rapor formatı)” ile profesyonel çıktı üretimini birleştirir. Ayrıca IT ve OT ortamlarında müdahale farklarını ve “ilk 60 dakika” (golden hour) yönetimini operasyonel bir runbook’a döker.

Bu Dersin Hedefleri

“Event” (kayıt) ile “Incident” (müdahale gerektiren olay) ayrımını doğru kurup olay tipini hızla daraltabileceksin.
İlk yaklaşımda “Bu belirtiyi ne doğrular, ne çürütür?” sorusuyla kanıt toplama planı çıkarabileceksin.
SOC/CSIRT entegrasyonunda doğru eskalasyon, doğru paket, doğru zaman disiplinini uygulayabileceksin.
OT/ICS bağlamında safety + süreklilik önceliklerini bozmadan müdahale kararlarını çerçeveleyebileceksin.
“Bulgu → Etki → Öneri → Kanıt” formatında denetlenebilir rapor üretebileceksin.
İlk 60 dakika runbook’u ile: hazırlık → uygulama → doğrulama → kanıt paketleme → rollback akışını yürütebileceksin.

11.1 Network olay tipleri ve ilk göstergeler

Network olayı; ağ trafiği, ağ cihazları veya ağ kimlik/erişim katmanında görülen bir sapmanın güvenlik etkisi doğurma ihtimali taşımasıdır. Kritik ayrım şudur:

Kayıt

Event

Sistemde gerçekleşen herhangi bir durum (login, policy reload, DNS sorgusu, deny/allow).

Müdahale

Incident

İş sürekliliğini, gizliliği veya bütünlüğü tehdit eden; kanıtla desteklenmiş somut sapma.

Her log satırı bir “incident” değildir; ama her “incident” mutlaka birden fazla veri kaynağında iz bırakır.

Etki / risk (operasyonel sonuç)

Yanlış sınıflandırma → yanlış müdahale: Örn. geçici kapasite dalgalanmasını “DDoS” sanıp agresif bloklamayla kendi servisini kesmek.
Semptom düzeldi yanılgısı: Trafik kesilir ama kök neden (policy drift / yanlış rota / kalıcı tünel / yanlış DNS) sürer.
En kritik risk: Kanıt yetersizliği nedeniyle kararın savunulamaması (denetim, post-incident inceleme, tuning).

Tespit sinyali / kanıt — ilk göstergeler

Aşağıdakiler ilk göstergedir; tek başına hüküm değildir.

Gösterge	Örnek sinyal	Tipik kaynak
Kimlik / erişim	VPN oturum artışı, beklenmeyen saat, çoklu başarısız doğrulama (802.1X/NAC/RADIUS), cihaz profili değişimi	VPN/NAC/RADIUS, kimlik platformu
Beklenmeyen egress	Normalde dışarı çıkmayan sunucu/cihazın dış hedeflerle konuşması	FW allow, proxy, flow
Port / servis sapması	Yönetim/yan hizmetlere yönelim artışı (yayılma izlenimi)	FW/ACL, flow, NDR/IDS özeti
DNS	Periyodik sorgular, NXDOMAIN oranı, beklenmeyen resolver	DNS sunucu/client, proxy/SWG
NTP / saat	Saat kayması → korelasyon hatası	NTP, sistem logları
Policy drift	Plan dışı konfig, firmware/patch penceresi dışı değişiklik	Change log, config diff, audit

Dikkat (triage tuzağı): “Deny log arttı = saldırı” değildir. Yeni uygulama devreye girmiş olabilir. Değişiklik kaydı yoksa olay olasılığı yükselir; varsa tasarım/iletişim hatası olasılığı artar.

Savunma kontrolü / düzeltme yaklaşımı

İlk hedef “hemen engelle” değil; olay türünü daraltacak en düşük riskli kanıtı toplamak.
Tek kontrol yerine iki bağımsız kanıt hedefle (örn. FW log + flow; VPN log + endpoint bağlantı özeti).
Düzeltme, doğrulama kanıtı üretilmeden “tamamlandı” sayılmaz.

11.2 İlk yaklaşım

İlk yaklaşım; olayın ilk dakikalarında kanıt → hipotez → doğrulama döngüsünü kurma disiplinidir. “Hız” değil, doğru hız önemlidir: yanlış pozitif maliyeti (iş kesintisi) ile kaçırma maliyeti (ihlalin büyümesi) dengelenir.

Kanıt

Zaman penceresi, etkilenen varlık ve en az iki bağımsız kaynakla “minimum kanıt seti”ni sabitle.

Hipotez

En az üç olasılık yaz (planlı değişiklik, drift, gerçek anomali); her biri için çürütülecek kanıtı seç.

Karar

Geniş izolasyondan önce en düşük riskli müdahale; rollback ve ticket’ta aynı dil.

Etki / risk

Erken ve geniş izolasyon, yanlış pozitifse doğrudan kesintiye gider.
Erken “temizleme” (servis restart, log üzerine yazma, sistem kapatma), kanıtı yok eder; kök neden körleşir.
Saat senkron bozuksa, tüm korelasyon yanlış yola sapar.

Tespit sinyali / kanıt

İlk 15–30 dakikada hedef “minimum kanıt seti”dir:

Zaman penceresi: başlangıç–bitiş tahmini
Etkilenen varlıklar: kaynak/hedef, subnet/zone, kullanıcı/cihaz
Kanıt türleri: FW/Proxy/VPN/DNS log kesiti + flow özeti; gerekirse kısa pcap dilimi

Savunma kontrolü / düzeltme yaklaşımı

“Bu belirtiyi ne doğrular, ne çürütür?” sorusunu ticket/runbook’a yazılı geçir.
Önce görünürlük açığını kapat: log yoksa hüküm yoktur.
Mümkünse en düşük riskli müdahaleyle başla: dar kapsamlı blok/rate-limit/ek log (tam karantina değil).

İpucu (karşı kanıt): Her hipotez için alternatif açıklama yaz (planlı değişiklik, yanlış DNS, rota değişimi, policy deploy). Sonra bu alternatifleri çürütecek kanıtı seç.

11.3 CSIRT/SOC entegrasyonu

Olay müdahalesi tek kişilik bir iş değildir. SOC/CSIRT entegrasyonu; eskalasyon, görev paylaşımı, delil paylaşımı, iletişim ve geri bildirim döngüsünü kurar.

Etki / risk

Yanlış severity, kaynakları boşa harcar veya kritik olayı geciktirir.
Ham log yığını göndermek, korelasyonu zorlaştırır; “kanıt paketi” gerekir.
İletişim disiplinsizliği panik ve hatalı müdahale doğurur.

SOC/CSIRT’ye gidecek minimum paket

Özet: ne oldu / ne zaman / hangi varlık (tek paragraf)
Etkilenen kapsam: servis–kullanıcı–zone
Kanıt ekleri: zaman pencereli log kesitleri + flow/pcap özetleri + (salt okuma) konfig snapshot
Aksiyonlar: yapılan değişiklikler + rollback planı
Belirsizlik notu: kesin olan (kanıt) / çıkarım (yorum) ayrımı

İletişim zinciri

Teknik lider (CSIRT): operasyon kararları
Ağ operasyon: kontrol değişiklikleri ve rollback
Hukuk/uyum: bildirim yükümlülükleri
PR/iletişim: dış iletişimde tek ağız

Severity (örnek)

P1: iş durdu / kritik veri riski
P2: kısmi etki / sınırlı yayılım
P3: tekil uç; düşük etki (kanıtla izlenir)

Savunma kontrolü / düzeltme yaklaşımı

Tek gerçek kaynağı oluştur: olay numarası/ticket.
Deconfliction yönet: ağ ekibi değişiklik yaparken IR ekibi kanıt topluyor olabilir.
Post-incident: alarm kalite döngüsü (tuning + yeni korelasyon + kontrol iyileştirmesi).

11.4 OT olaylarına özel mini çerçeve

OT/ICS’de müdahale, IT’den farklı olarak safety ve üretim sürekliliği baskısı taşır. “Şüpheli cihazı kapat” refleksi, fiziksel süreçlerde tehlikeli sonuçlar doğurabilir.

IT odak

Hızlı izolasyon ve yama seçenekleri daha sık devrededir; kesinti çoğu zaman bilgi/iş süreci maliyetidir.

OT odak

Safety ve süreklilik önce gelir; görünürlük ve pasif doğrulama, acele kapatmadan önce sıklıkla doğru adımdır.

Etki / risk

Yanlış izolasyon/segment kapatma üretimi durdurabilir.
OT varlıklarında yeniden başlatma/yama maliyeti yüksek olabilir.
Güvenlik aksiyonu fiziksel süreci etkileyebileceğinden “safety onayı” gerekebilir.

Tespit sinyali / kanıt

OT’de “normalden sapma” güçlü sinyaldir: yeni konuşan cihaz, yeni zaman penceresi, beklenmeyen yön/akış.
Kanıt kaynakları: OT gateway logları, FW/ACL logları, pasif trafik özetleri, jump server erişim kayıtları.

Savunma kontrolü / düzeltme yaklaşımı

İlk müdahale: görünürlük + pasif doğrulama (en düşük risk).
Aksiyonlar: OT mühendisiyle birlikte “etki analizi → kontrollü değişiklik → rollback”.
Fail-open / fail-close kararı: kontrol arızasında sistemin açık mı kapalı mı kalacağı OT’de kritik bir risk değerlendirmesidir.

Dikkat: OT’de doğru hamle bazen “önce log + daraltılmış izleme”dir. Kanıt kalitesi ve kesinti riski kararın parçasıdır.

11.5 Raporlama (Bulgu → Etki → Öneri → Kanıt)

Rapor, olayın “hafızasıdır” ve denetlenebilir karar dosyasıdır. En kritik ayrım: gözlem (kanıt) ≠ yorum (çıkarım).

Raporlama dili

“X ülkesinden saldırı” gibi kesin çıkarımlar yerine: “IP coğrafi konum verisi Y bölgesini işaret ediyor (kanıt); aktör atfı belirsiz (yorum)” disiplinini koru. Her cümlede kanıt referansı veya belirsizlik notu olsun.

Etki / risk

Zayıf rapor: aynı olay tekrar eder; tuning yapılamaz.
Kanıtsız rapor: uyum/iç denetimde savunulamaz.
Aşırı kesin dil: belirsizlik yönetimini bozar.

Tespit sinyali / kanıt

Log/flow/pcap kesitleri: zaman pencereli, kaynak/hedef net, bağlam notlu
Konfig/policy snapshot: “o anki gerçek”
Kanıt paketi: dosya listesi + hash + kim aldı + nereden aldı + saat

Savunma kontrolü / düzeltme yaklaşımı

Bulgu: tek cümle, ölçülebilir, kanıt referanslı
Etki: iş + güvenlik + operasyon (kesinti, görünürlük, yayılma)
Öneri: kısa vadeli (hemen) + orta vadeli (kalıcı)
Kanıt: dosyalar + hash + saklama disiplini

11.6 HOW-TO: İlk 60 Dakika Runbook’u

Aşağıdaki runbook; yalnızca izinli/kurum içi yetkili ortam veya tamamen yerel lab varsayımıyla, “do not harm” ilkesini koruyarak kanıt standardında ilk müdahale akışını verir.

1Hazırlık0–10 dk · ticket · zaman

2Uygulama10–30 dk · hipotez · kanıt

3Doğrulama30–45 dk · karşı kanıt

4Kanıt45–55 dk · paket · hash

5Rollback55–60 dk · geri al · containment

Aşama 1 — Hazırlık (0–10 dk)

Olay kaydı aç: olay numarası, saat, bildirimi yapan, etkilenen servis/zone.
Zaman senkron notu: saat kayması şüphesi varsa “timeline riski” olarak yaz.
Kanıt klasörü/etiketleme: YYYYMMDD_HHMM_source_type.ext
Kapsam sınırı: tekil varlık/segment; genişletme için onay + gerekçe.
Değişiklik kaydı kontrolü: planlı deploy/bakım var mı?

Aşama 2 — Uygulama (10–30 dk)

Belirtiyi netleştir: egress, DNS, VPN, deny artışı, OT sapması.
Hipotezleri yaz (en az 3): planlı değişiklik / konfig drift / gerçek anomali.
Minimum kanıt seti — birincil: FW/VPN/DNS/Proxy log kesiti.
Minimum kanıt seti — ikincil: flow özeti veya kısa pcap (gerekiyorsa).
Bağlam: değişiklik kaydı (var/yok), varlık kritikliği.

Aşama 3 — Doğrulama (30–45 dk)

“Ne doğrular, ne çürütür?” tablosu: iddia → Kanıt A → Kanıt B → alternatif açıklama → karar eşiği.
Güvenli tekil doğrulama: tek hedef + tek servis (tarama yok).
Etkilenen varlık listesini daralt: kaç cihaz, hangi zone, hangi kullanıcı?

Aşama 4 — Kanıt paketleme (45–55 dk)

Kanıtları salt okunur sakla; export’ları ekle.
SHA-256 hash + “kim/ne zaman/nerede aldı” notu.
Kanıt setini arşivle ve ticket’a iliştir.

Aşama 5 — Geri dönüş / rollback (55–60 dk)

Yanlış pozitif ihtimali: geçici aksiyonların geri alma adımlarını uygula.
Gerçek olay güçleniyorsa: kapsamı büyütmeden, değişiklik yönetimiyle kontrollü containment planla (tam karantina kanıta dayalı olmalı).

Dikkat: 60. dakikada “her şeyi kapat” refleksi her zaman doğru değildir; kanıt kalitesi, OT/üretim etkisi ve geri alınabilirlik aynı kararın parçasıdır.

11.7 Komut & Araç Okuryazarlığı (Windows / Linux / macOS + Wireshark)

Aşağıdaki komutlar yalnızca denetim/okuma, tekil doğrulama, kanıt üretimi içindir. Geniş aralık tarama/hedef bulma/istismar/bypass “how-to” yoktur. Komutları mümkünse yerel konsol/izinli ortam üzerinden çalıştır; uzaktan bağlantıyı kesebilecek aksiyonlarda (host firewall/drop) önce rollback planı yaz.

Hızlı komut seti (özet)

Görev	Windows	Linux	macOS
Bağlantı özeti	`Get-NetTCPConnection`	`ss -tuna` / `ss -tulpn`	`netstat` (gerektiğinde)
PID eşleme	`netstat -ano`, `tasklist`	`ss -tulpn`	—
Komşu / rota	`arp -a`	`ip neigh`, `ip route`	`ifconfig`, `netstat -rn`
Sistem logu	`Get-WinEvent` (ihtiyaca göre)	`journalctl`	`log show`
Tekil test	`Test-NetConnection`	`nc -vz`	`nc -vz`
PCAP	—	`tcpdump`	`tcpdump`
Hash	`Get-FileHash`	`sha256sum`	`shasum -a 256`

1. Snapshot: uçucu veri ve bağlantı durumu

Windows (PowerShell + klasik)

A) Aktif bağlantılar

TCP bağlantıları

PS C:\evidence> Get-NetTCPConnection | Sort-Object -Property State,RemoteAddress,RemotePort | Out-File .\evidence\net_tcp_connections.txt -Encoding UTF8

Amaç: O anki bağlantı gerçekliğini kaydetmek
Yorum ipucu: Beklenmeyen RemoteAddress/RemotePort, kısa ömürlü çoklu oturumlar
Güvenli sınır: Yerel okuma

B) PID eşleme

netstat / tasklist

PS C:\evidence> netstat -ano > .\evidence\netstat_ano.txt; tasklist /v > .\evidence\tasklist_v.txt

Amaç: Bağlantıyı yapan süreç(ler)i PID üzerinden ilişkilendirmek
Güvenli sınır: Yerel okuma

C) ARP önbelleği

ARP

PS C:\evidence> arp -a > .\evidence\arp_cache.txt

Amaç: Yerel L2 komşuluk durumunu belgelemek
Güvenli sınır: Yerel okuma

Linux

A) Bağlantılar + dinleyen servisler

analist@soc:~/evidence$ ss -tuna > ./evidence/ss_tuna.txt; ss -tulpn > ./evidence/ss_tulpn.txt

Amaç: Aktif bağlantılar ve dinleyen servisleri kanıta almak
Güvenli sınır: Yerel okuma

B) ARP / komşuluk ve rota

ip neigh / route

analist@soc:~/evidence$ ip neigh show > ./evidence/ip_neigh.txt; ip route show > ./evidence/ip_route.txt

Güvenli sınır: Yerel okuma

C) Sistem kayıtları

journalctl

analist@soc:~/evidence$ journalctl --since "1 hour ago" > ./evidence/journal_last1h.txt

Güvenli sınır: Yerel okuma

macOS

A) Ağ / rota snapshot

ifconfig / netstat

analist@MacBook evidence % ifconfig > ./evidence/ifconfig.txt; netstat -rn > ./evidence/routes.txt

Güvenli sınır: Yerel okuma

B) Zaman pencereli sistem logu

log show

analist@MacBook evidence % log show --last 1h > ./evidence/macos_log_last1h.txt

Güvenli sınır: Yerel okuma

2. Tekil servis doğrulaması (tarama değil)

Windows

Test-NetConnection

PS C:\evidence> Test-NetConnection -ComputerName 198.51.100.10 -Port 443

Amaç: Tek hedef + tek port erişilebilirlik doğrulaması
Yorum ipucu: False ise “policy mi, servis mi?” için ikinci kanıt ara
Güvenli sınır: Tek hedef/tek servis

Linux / macOS

analist@soc:~/evidence$ nc -vz 198.51.100.10 443

Amaç: Tekil TCP port doğrulaması
Güvenli sınır: Tek hedef/tek servis

3. PCAP kanıtı (kısa, kontrollü, düşük risk)

tcpdump — triage dilimi

analist@soc:~/evidence$ sudo tcpdump -i eth0 -w ./evidence/triage_slice.pcap -G 60 -W 1 -s 128

Amaç: Kısa “kanıt dilimi” (mümkünse SPAN/TAP)
Güvenli sınır: Düşük süre, düşük snaplen; payload hassasiyeti

Dikkat: Gerçek ortamda pcap hassas içerik taşıyabilir. Erişim ve saklama; kurum politikası + yetki + minimizasyon ile yapılır.

4. Wireshark okuryazarlığı (kanıt üretmek için)

Nasıl yakalarım? Capture → Options; doğru arayüz (SPAN/TAP tercih); ring buffer ile disk şişmesini önle; gerekirse capture filter ile daralt.

Nasıl okurum?

Statistics → Conversations / Endpoints: “kim kiminle konuşuyor?” hızlı özet
Statistics → Protocol Hierarchy: protokol dağılımı
Analyze → Expert Information: reset/handshake sorunları
Follow → TCP Stream: yalnız eğitim/sentetik içerikte

Display filter örnekleri

Amaç	Örnek filtre
TLS (443)	`tcp.port == 443`
Belirli hedef	`ip.dst == 198.51.100.99`
DNS sorgu (yanıt yok paterni)	`dns.flags.response == 0`
HTTP POST yoğunluğu	`http.request.method == "POST"`

Nasıl kanıta çeviririm?

Conversations/Endpoints ekran görüntüsü + pcap hash’i + zaman penceresi notu
Bulgu için: kaynak/hedef, port, oturum sayısı, zaman dağılımı

5. Kanıt bütünlüğü ve paketleme

Windows

Get-FileHash

PS C:\evidence> Get-FileHash .\evidence\triage_slice.pcap -Algorithm SHA256 | Out-File .\evidence\hashes_sha256.txt -Encoding UTF8

Güvenli sınır: Yerel

Linux

Hash + arşiv

analist@soc:~/evidence$ sha256sum ./evidence/* > ./evidence/hashes_sha256.txt; tar -czf evidence_bundle.tar.gz ./evidence

Güvenli sınır: Yerel

macOS

shasum

analist@MacBook evidence % shasum -a 256 ./evidence/* > ./evidence/hashes_sha256.txt

Güvenli sınır: Yerel

11.8 Operasyonel Senaryo (izinli/uydurma): “Gece Yarısı Veritabanı Trafiği”

Senaryo uydurma verilerle örneklendirilmiştir; amaç suç atfetmek değil, kanıt zinciriyle doğru hipotezi bulmaktır.

Belirti

SOC, Cumartesi 02:45’te 192.0.2.50 (finans DB) üzerinden beklenmeyen TLS egress ve hacim artışı; aynı pencerede FW deny artışı.

Toplanacak kanıt

FW allow/deny (02:30–03:00)
Bağlantı snapshot (Get-NetTCPConnection / ss -tuna)
60 sn pcap + Conversations/Endpoints
Değişiklik kaydı (02:00–03:00)

Hipotez tablosu

#	Hipotez	Not
1	Planlı değişiklik	Entegrasyon/backup egress (meşru)
2	Policy drift	Yanlış deploy; egress yolu açıldı/kapandı
3	Gerçek anomali	Rol uyumsuz hedefler; zayıf egress kontrolü

Uydurma kanıt kesitleri

FW log (uydurma)

Örnek satırlar

2026-02-10T02:46:12Z action=ALLOW src=192.0.2.50 dst=198.51.100.99 dst_port=443 rule=Egress_Web_Allow 2026-02-10T02:47:01Z action=DENY src=192.0.2.50 dst=203.0.113.20 dst_port=443 rule=Default_Deny

Bağlantı özeti (uydurma)

192.0.2.50 → 198.51.100.99:443 (çoklu kısa oturumlar, aralıklı tekrar)

Değişiklik kaydı (uydurma)

02:10–02:30 “Entegrasyon servisi devreye alımı” (var/yok)

Analiz

Zaman korelasyonu: allow/deny ↔ bağlantı snapshot ↔ değişiklik kaydı.
Planlı değişiklik: kayıt + iş gerekçesi + kural adı tutarlı mı?
Policy drift: kural diff / hit-count sıçraması?
Gerçek anomali: hedef çeşitliliği, rol uyumu, default deny paterni?
İkinci kanıt: pcap özetinde hedef/oturum paterni.

Karar

Değişiklik kaydı + rol uyumlu + kanıt tutarlıysa: incident değil; iletişim/change kaydı açığı.
Kayıt yok + rol uyumsuz + şüpheli patern: incident şüphesi; containment kanıt paketinden sonra.

Rapor özeti (Bulgu → Etki → Öneri → Kanıt)

Bulgu: 192.0.2.50 → 198.51.100.99:443 TLS artışı; eş zamanlı deny artışı.
Etki: Egress/görünürlük zayıflığı; yanlış müdahalede kesinti riski.
Öneri: Egress’i iş gerekçesiyle daralt; change sıkılaştır; korelasyon + tuning; baseline güncelle.
Kanıt: FW kesitleri, snapshot, pcap özeti, SHA-256.

Terimler Sözlüğü

Terim	Türkçe karşılığı / açıklama
Event	Kayıt/olay kaydı; her event bir incident değildir
Incident	Müdahale gerektiren güvenlik olayı
IoC	Uzlaşma göstergesi (iz/sinyal)
Triage	Sınıflandırma ve önceliklendirme
Containment	Yayılmayı sınırlama/izolasyon (kontrollü)
Volatile data	Uçucu veri (enerji kesilince kaybolabilen)
Chain of custody	Kanıtın kimde/ne zaman nasıl tutulduğunun izlenebilirliği
Policy drift	Politikanın hedeflenen “golden” durumdan sapması
Forensic soundness	Kanıtı gereksiz değiştirmeden çalışma disiplini
CSIRT/SOC	Olay müdahale ekibi / güvenlik operasyon merkezi
OT/ICS	Operasyon teknolojileri / endüstriyel kontrol sistemleri

Kendini Değerlendir

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

Aşağıdakilerden hangisi “incident” kararını en doğru şekilde güçlendirir?

A) Firewall deny sayısı arttı.

B) Tek bir uç noktada tek seferlik DNS hatası görüldü.

C) Aynı zaman penceresinde FW allow log + flow özetinde rol uyumsuz yeni dış hedefler + değişiklik kaydı yok.

D) Kullanıcı “internet yavaş” dedi.

E) Wireshark’ta TLS paketleri görüldü.

Doğru: C
Gerekçe: Incident için çoklu bağımsız kanıt + bağlam (değişiklik kaydı yokluğu) gerekir. A/E tek başına yorumdur; D/B zayıf sinyal.

İlk 15 dakikada en doğru öncelik sıralaması hangisidir?

A) Hemen tüm outbound’u kapat, sonra loglara bak.

B) Önce kanıt klasörü/etiketleme + zaman penceresi + minimum kanıt seti, sonra dar kapsamlı doğrulama.

C) Sistemi kapat, böylece saldırgan çıkar.

D) Ham logları SOC’ye olduğu gibi gönder.

E) “Kesin saldırı” diye yönetimi bilgilendir.

Doğru: B
Gerekçe: Kayıt/kanıt disiplini ve minimum kanıt seti, yanlış pozitif ve kanıt kaybı riskini azaltır. A/C kesinti ve kanıt kaybı doğurabilir; D gürültü; E belirsizlik yönetimini bozar.

Aşağıdakilerden hangisi gözlem–yorum ayrımına en uygundur?

A) “Saldırgan kesin dış ülkeden.”

B) “IP coğrafi konum verisi dış bölgeyi işaret ediyor; aktör atfı belirsiz.”

C) “Bu kesin veri sızıntısıdır.”

D) “Sistem temiz, çünkü ping atıyor.”

E) “Deny arttı, saldırı var.”

Doğru: B
Gerekçe: Kanıta dayalı ifade + belirsizlik notu içerir. Diğerleri kesinlik iddiası ve tek sinyale aşırı yükleme hatasıdır.

“Karşı kanıt” yaklaşımının en iyi örneği hangisidir?

A) Sadece alarmı doğrulayan logları toplamak.

B) “Planlı değişiklik olabilir” deyip hiç kanıt toplamamak.

C) Her hipotez için alternatif açıklama yazıp, bunu çürütecek ikinci bağımsız kanıt aramak.

D) Tüm trafiği kesmek.

E) Sadece Wireshark ekranına bakmak.

Doğru: C
Gerekçe: Karşı kanıt; alternatif açıklamaları test etmeyi ve hatalı hükmü azaltmayı hedefler.

OT ortamında en doğru ilk yaklaşım hangisidir?

A) Şüpheli cihazı anında kapat.

B) Fail-close yap, üretim dursa da önemli değil.

C) OT mühendisiyle koordinasyon + pasif doğrulama + etki analizi → kontrollü değişiklik.

D) IT ekibi tek başına karar versin.

E) Kayıt tutmaya gerek yok, önemli olan durdurmak.

Doğru: C
Gerekçe: OT’de safety/süreklilik önceliklidir; kontrollü, koordineli ve kanıta dayalı yaklaşım gerekir.

SOC/CSIRT’ye “doğru paket” hangisini içerir?

A) Sadece ham log yığını.

B) Sadece bir ekran görüntüsü.

C) Özet + zaman pencereli ilgili log kesitleri + flow/pcap özeti + alınan aksiyonlar + rollback planı.

D) “Her şey normal” mesajı.

E) Sadece tahminler.

Doğru: C
Gerekçe: Korelasyon ve karar için bağlam, kanıt ve aksiyon kaydı birlikte olmalıdır.

Aşağıdaki seçeneklerden hangisi “kanıt bütünlüğü” açısından en iyisidir?

A) Kanıt dosyalarını düzenleyip yeniden kaydetmek.

B) Kanıtı tek bir klasöre atıp isimlendirmemek.

C) Dosya isim standardı + zaman penceresi notu + SHA-256 hash + kim aldı kaydı.

D) Logları kopyalayıp orijinali silmek.

E) Kanıtı e-posta ile herkesle paylaşmak.

Doğru: C
Gerekçe: İzlenebilirlik (chain of custody) ve bütünlük hash ile korunur; diğerleri kanıtı zayıflatır.

“Deny log arttı” sinyali için en doğru yorum hangisidir?

A) Kesin saldırı var.

B) Kesin yanlış konfig var.

C) Tek sinyal; değişiklik kaydı + allow/flow korelasyonu ile anlam kazanır.

D) Hiç önemli değil.

E) Hemen tüm portları açmak gerekir.

Doğru: C
Gerekçe: Deny artışı hem meşru değişiklikten hem olaydan kaynaklanabilir; korelasyon şarttır.

Wireshark’ta “Conversations/Endpoints” ekranının runbook’taki rolü nedir?

A) Saldırıyı yapmak için hedef seçmek.

B) “Kim kiminle konuşuyor?” özetini vererek kanıtı hızlı daraltmak.

C) Şifreleri çözmek.

D) Ağ topolojisini çıkarmak için tarama yapmak.

E) Logları silmek.

Doğru: B
Gerekçe: Amaç, özet istatistikle kanıt üretmek ve kapsamı daraltmaktır; saldırı amaçlı kullanım yoktur.

Aşağıdakilerden hangisi “rollback” düşüncesini en iyi yansıtır?

A) “Ne yaparsak yapalım geri alamayız.”

B) Geçici aksiyonları (dar blok/rate-limit) kayda geçirip yanlış pozitifse hızla geri almak.

C) Tüm sistemi formatlamak.

D) Kanıt toplamadan izolasyon yapmak.

E) Sadece yönetimi bilgilendirmek.

Doğru: B
Gerekçe: Rollback; do-not-harm ve operasyon sürekliliği için kontrollü, geri alınabilir aksiyonları zorunlu kılar.

Kapanış: Bu modülde kazandıkların

Event–incident ayrımıyla doğru sınıflandırma, doğru eskalasyon ve doğru kayıt disiplini
“Ne doğrular, ne çürütür?” ile karşı kanıt refleksi ve belirsizlik yönetimi
SOC/CSIRT entegrasyonunda kanıt paketleme ve iletişim zinciri
OT’de safety/süreklilik odaklı kontrollü müdahale çerçevesi
“Bulgu → Etki → Öneri → Kanıt” formatında denetlenebilir raporlama
İlk 60 dakikayı panikle değil runbook ile yönetme

MODÜL 12 — Yetkili Keşif, Güvenli Doğrulama, Purple Team Raporlama (Operasyonel Omurga)

Kavramsal şema: yazılı yetki ve ROE; kırmızı senaryo ile mavi tespitin mor alanda birleşmesi; kanıtlı güvenli doğrulama; çıktının rapor, KPI ve düzeltme takibiyle omurga haline gelmesi.

Bu modül, önceki modüllerde kurduğun savunma ve izleme yeteneklerini sahada doğrulama disiplinine taşır: Yetkili keşif ile kör noktaları aydınlatır, otomatik bulguları “zafiyet okuryazarlığı” ile doğru sınıflandırır, istismar etmeden güvenli doğrulama yapar ve purple team yaklaşımıyla “kontrol gerçekten çalışıyor mu?” sorusunu ölçülebilir hale getirirsin. Amaç “bir şey buldum” demek değil; bulguyu (kanıt), etkisini (iş/operasyon riski), öneriyi (kontrol iyileştirmesi) ve kanıtı (log/flow/pcap + bütünlük) tek zincirde birleştirip denetlenebilir bir çıktı üretmektir. Buradaki keşif “hedef arama” değildir; izinli kapsam içinde envanter doğruluğu + görünürlük üretme disiplinidir. Doğrulama “sömürme” değildir; tekil, düşük riskli, ölçülebilir kontrollerle “maruziyet var mı?” sorusuna cevap üretmektir. Purple team, saldırı yapmak değil; savunma kontrollerinin tuning ve ölçüm döngüsünü çalıştırmaktır. Sonuç: Bu modül, güvenlik çalışmasını “tespit → karar → rapor” hattına sokar.

Bu Dersin Hedefleri

Yetkili keşfi pasif/aktif (düşük risk) bileşenleriyle tasarlayıp kapsam sınırlarına sadık kalabileceksin.
Kayıtsız/unutulmuş varlıkları (Shadow IT) görünür kılma ve “yaşayan envanter” üretme yaklaşımını uygulayabileceksin.
Otomatik tarayıcıların “yüksek risk” uyarılarını false positive olasılığıyla birlikte yorumlayıp güvenli doğrulama planı çıkarabileceksin.
“Açık port ≠ zafiyet” ayrımını operasyonel karara dönüştürecek; CVE/misconfig/exposure sınıflandırmasını net yapabileceksin.
Purple team simülasyonlarında başarı kriteri, veri kaynağı, tespit sinyali ve rollback planını aynı çerçevede yönetebileceksin.
PCAP/flow/log kanıtlarını aynı zaman penceresinde birleştirip rapora kanıt–yorum ayrımını koruyarak bağlayabileceksin.
“Bulgu → Etki → Öneri → Kanıt (rapor formatı)” ile yönetim ve teknik ekip için doğru seviyede çıktı üretebileceksin.
Envanter → risk matrisi → rapor zinciri HOW-TO’su ile bulguyu kurumsal karar mekanizmasına taşıyabileceksin.

12.1 Yetkili reconnaissance metodolojisi

Yetkili keşif; kurumun izni ve bilgisi dahilinde, savunmayı güçlendirmek amacıyla harita çıkarmaktır: varlıkları, ağ yollarını, güvenlik kontrollerini ve görünürlük kaynaklarını sistematik biçimde ortaya koymak. Burada amaç “hacklemek” değil; envanter doğruluğu ve telemetri kapsaması üretmektir.

1RoEKapsam · kurallar · stop

2KaynaklarCMDB · DNS · DHCP · FW

3PasifLog · flow · gözlem

4DoğrulamaTekil · düşük risk

Metodoloji hattı (özet)

1 · RoE — Kapsam ve kurallar (Modül 0): neyin içinde, hangi zaman penceresinde, stop/kill koşulları.
2 · Kaynaklar — CMDB, DNS, DHCP, NAC, FW, flow; otoritatif veya salt okunur çıktılar.
3 · Pasif — Log ve flow ile gözlem; önce kanıt, sonra müdahale.
4 · Doğrulama — Gerekiyorsa tekil, düşük riskli doğrulama (tek servis / tek varlık).

Etki / risk (operasyonel sonuç)

Bilinmeyen varlık korunamaz, yamalanamaz, izlenemez: en büyük risk körlüktür. Shadow IT çoğu zaman “saldırı” değil, “kontrol dışı büyüme” ile oluşur; ama etkisi saldırı kadar ağır olabilir.
Plansız aktif doğrulama üretim etkisi doğurabilir; bu yüzden yoğunluk, zaman penceresi ve rollback önceden tanımlanır.
Yanlış kapsam, hukuki/etik ihlal ve güven kaybıdır (white-hat disiplinine aykırı).

Tespit sinyali / kanıt (log/flow/pcap nerede?)

Yetkili keşfin çıktısı “kanıtlanabilir görünürlük” olmalıdır:

Envanter kanıtı: DHCP lease özeti, DNS kayıt örnekleri, NAC cihaz profili (salt-okuma)
Akış kanıtı: flow özetleriyle “hangi subnet kimle konuşuyor?” matrisi
Kontrol kanıtı: FW/ACL politika snapshot (salt-okuma export), change log kesiti
Zaman penceresi: hangi gün/saat alındı (korelasyon için)

Savunma kontrolü / düzeltme yaklaşımı

“Tek kaynakla envanter olmaz”: en az iki bağımsız kaynaktan doğrula (örn. DHCP + switch MAC tablosu; DNS + uygulama envanteri).
Düzenli periyotla “yaşayan envanter” üret ve CMDB ile fark analizi yap.
Görünürlük boşluklarını sınıflandır: eksik syslog/flow exporter, yanlış zaman senkronu, yanlış asset etiketi.

Yaşayan envanter tablosu (şablon)

Sütunlar: IP ve MAC kimlik; İşletim sistemi ve servis/port için hücrede tahmini (banner, fingerprint, zayıf sinyal) ile kanıtlı (NAC, ajan, komut çıktısı, yama kaydı) ayrımını not edin. Rol / sahip ve veri kaynağı sütunları aynı satırda çelişki avı için kullanılır.

IP adresi	MAC	İşletim sistemi (tahmini / kanıtlı)	Servis / port (dinleyen veya görülen; kanıt türü)	Rol / sahip	Veri kaynağı	Kanıt zamanı (UTC)	Not
192.0.2.45	aa:bb:cc:dd:ee:ff	Windows 11 — kanıtlı (NAC profili + AD)	443/tcp, 5985/tcp — kanıtlı (`ss` / Get-NetTCPConnection)	Muhasebe · İş istasyonu · Ayşe Y.	NAC, DHCP lease, CMDB	2026-04-17T11:00:00Z	CMDB ile uyumlu; flow’da beklenen iç egress.
198.51.100.8	— (flow NAT)	Linux — tahmini (TLS/JA3; sürüm için ajan yok)	22/tcp — kanıtlı (firewall allow log + flow)	Etiketsiz / sahipsiz	Flow + FW; CMDB boş	2026-04-17T11:05:00Z	Shadow IT adayı — çapraz doğrulama kuyruğuna al.

Nasıl okunur? İlk satır “kimliği ve yüzeyi kanıtlı” örnek; ikinci satır OS’i tahmine yakın tutup portu logla sabitlediği için önceliklendirme farklıdır.

Dikkat: Bu modülde “keşif” adı altında geniş aralık tarama/hedef bulma yaklaşımı yoktur. Esas; envanter ve telemetri doğruluğu üretmektir.

12.2 Zafiyet okuryazarlığı ve güvenli doğrulama

Zafiyet okuryazarlığı; bir bulguyu doğru etiketleyip doğru aksiyona bağlamaktır. Üç sınıfı ayırt et:

CVE

Ürün/yazılım zafiyeti; yama ve versiyon bağlamı kritik.

Misconfiguration

Yanlış kural, zayıf TLS, aşırı izin, hatalı egress veya segment.

Exposure

Gereksiz açık yüzey; yanlış segmente veya dışa açık servis, yanlış rota.

İpucu (sınıflandırma): Ana refleks “Açık port ≠ zafiyet.” Açık bir port yalnızca yüzeydir; risk, portun arkasındaki servis ve konfigürasyon bağlamıyla oluşur.

1CVEÜrün · yama · versiyon

2MisconfigurationKural · policy · TLS

3ExposureYüzey · segment · rota

Etki / risk (operasyonel sonuç)

Yanlış sınıflandırma yanlış çözüm üretir: CVE sanıp yama kovalarken aslında policy drift veya misconfig kaçabilir.
Otomatik tarayıcılar çıktı üretir; ancak “karar” veremez. False positive mümkündür. Özellikle “banner/versiyon” üzerinden risk tahmini yapılırsa, sistemde geriye dönük yamalama/backporting gibi durumlar sinyali çarpıtabilir.
Aşırı agresif doğrulama “do not harm” ihlaliyle kesintiye götürebilir.

Tespit sinyali / kanıt (log/flow/pcap nerede?)

Maruziyet kanıtı: tekil servisin sertifika zinciri/konfig çıktısı, kural hit-count, allow/deny kayıtları, config snapshot
Etkileşim kanıtı: tekil bağlantı doğrulama sonucu (başarılı/başarısız), ilgili servis logu (erişim var/yok)
Karşı kanıt: “Bu belirtiyi ne çürütür?” (ör. kural var ama hiç hit almıyor; log yok çünkü kaynak yanlış)

Savunma kontrolü / düzeltme yaklaşımı

Doğrulamada her zaman “en az riskli” yolu seç: önce konfig/policy/sertifika → sonra tekil bağlantı kontrolü.
“Kanıt = ölçülebilir çıktı”: komut çıktısı + zaman damgası + hash + bağlam notu.
Düzeltmeyi iki katmanlı düşün: kısa vadeli (daralt/tune et/limit koy) + kalıcı (policy/mimari/sertifika yönetimi/segment düzelt).

BYPASS / erişim farkındalığı (yalnızca savunma diliyle)

Kategori: aşırı izinli egress kuralı
Amaç (kavramsal): dışarıya kontrolsüz çıkış elde etmek
Beklenen iz/sinyal: beklenmeyen hedeflere periyodik TLS oturumları (flow + proxy log)
Savunma kontrolü: egress allowlist, proxy policy, NDR davranış tespiti
Kanıt örneği (uydurma): “198.51.100.10:443 hedefine kısa oturum tekrarları” flow özeti

12.3 Simülasyon metodolojisi (purple team mantığı)

Purple team; kırmızı (senaryo/simülasyon) ile mavi (savunma, SIEM, hunt) bakışının birlikte ölçülmesidir. Ortak soru:

1KırmızıSenaryo · kapsam · süre

2MaviTespit · alarm · log

3MorÖlçüm · tuning · öğrenme

Kırmızı

Kontrollü, geri alınabilir davranış örüntüsü; kapsam ve süre yazılı.

Mavi

Önleme, tespit, görünürlük: kural, alarm ve log üretimi.

Mor (kesişim)

“Ölçülebilir çıktı mı?” sorusu; tuning ve runbook güncellemesi.

“Eğer X davranışı olsaydı, kontrol engeller mi (prevention), alarm üretir mi (detection), en azından log’a düşer mi (visibility)?”

Simülasyon; düşük riskli, geri alınabilir, ölçülebilir bir davranış örüntüsü üretir. Amaç “saldırı yapmak” değil; savunma kurgusunun gerçekten çalışıp çalışmadığını görmek ve iyileştirmektir.

Etki / risk (operasyonel sonuç)

Plansız simülasyon gürültü üretir, SOC’u yorar, yanlış tuning’e sebep olur.
Başarı kriteri yoksa ölçüm yoktur; “yaptık” kalır.
Rollback planı yoksa üretim riski doğar.

Tespit sinyali / kanıt

Simülasyonu şu zincire bağla:

Davranış → Sinyal (örn. periyodik kısa TLS oturumları → flow periyodiklik + proxy erişim log)
Sinyal → Veri kaynağı (FW log, proxy, DNS, NDR/IDS, endpoint ağ telemetrisi)
Kanıt → Çıktı (olay kaydı/alarm kimliği, log kesiti, flow özeti, gerekiyorsa kısa pcap)

Savunma kontrolü / düzeltme yaklaşımı

Simülasyonu minimize et: düşük hacim, kısa süre, tek test varlığı/tek segment.
Tuning döngüsü: yanlış pozitif → kural rafine → tekrar simülasyon → ölçüm.
“Lessons learned” listesi üret: veri kaynağı eksik mi, zaman senkronu sorunlu mu, runbook uygulanabilir mi?

Dikkat: Purple team senaryoları “nasıl sızarım?” içeriği değildir. Davranış yalnızca savunmayı ölçmek içindir; istismar/kimlik bilgisi elde etme/zarar verme yoktur.

12.4 PCAP/log/flow kanıtlarının raporda birleştirilmesi

Tek bir veri türü olayı anlatmaya yetmez. Triangülasyon: aynı zaman penceresinde çapraz doğrulama.

1FlowÖzet · hacim · kim–kime

2LogKural · kimlik · bağlam

3PCAPOturum · kısa dilim

Flow

Kim kiminle, ne kadar, ne sıklıkta — genel resim ve hacim.

Log

Kural, kimlik, uygulama olayı — politika ve bağlam.

PCAP

Oturumun teknik gerçekliği; kısa dilim, minimizasyon ve yetki.

Amaç; bu kaynakları aynı zaman penceresinde birleştirip kanıt–yorum ayrımını koruyarak rapora bağlamaktır.

Etki / risk

Tek kaynağa dayanmak yanlış pozitif/negatif riskini artırır.
Zaman damgası uyumsuzluğu hikâyeyi bozar.
Ham PCAP’ın yanlış saklanması gizlilik riskidir; minimizasyon ve yetki şarttır.

Tespit sinyali / kanıt

Zaman çizelgesi: T0 alarm → T1 doğrulama → T2 kontrol değişikliği → T3 geri dönüş
Kanıt seti: log kesiti + flow özeti + kısa pcap + config snapshot + hash listesi
Bağlam notu: hangi kural, hangi zone, hangi iş servisi

Savunma kontrolü / düzeltme yaklaşımı

Aynı olayı farklı kaynaklardan referansla: log satırı ↔ flow kaydı ↔ pcap özet ekranı/akış kimliği.
Kanıt paketini standardize et: isimlendirme, hash, “kim aldı/nereden aldı” kaydı.
Gizlilik: sadece gerekli kısmı topla; gereksiz payload analizine girme.

12.5 Bulgu → Etki → Öneri → Kanıt ile profesyonel çıktı

Bu format, teknik bulguyu iş kararına dönüştüren ortak dildir. Dört sütun:

1BulguKanıta bağlı · ölçülebilir

2Etkiİş · operasyon · süreklilik

3ÖneriHemen + kalıcı

4KanıtDosya · hash · kaynak

Bulgu

Kanıta bağlı, ölçülebilir tek cümle — ne oldu?

Etki

İş, operasyon, süreklilik — neden önemli?

Öneri

Kısa vadeli risk azaltma + kalıcı düzeltme — ne yapmalı?

Kanıt

İzlenebilir paket — nasıl biliyoruz?

Etki / risk

Format yoksa rapor “hikâye”ye döner, denetlenemez.
Kanıt yoksa karar savunulamaz; tuning ve değişiklik yönetimi zayıflar.
Aşırı kesin dil yanlış karar doğurur; belirsizlik dürüstçe yönetilmelidir.

Tespit sinyali / kanıt

Bulgu cümlesi mutlaka “hangi varlık + hangi davranış + hangi zaman” içerir.
Kanıt; dosya listesi + hash + kaynak sistemi + zaman penceresi.

Savunma kontrolü / düzeltme yaklaşımı

Önerileri iki katmanda yaz: “hemen” (risk azaltma) ve “kalıcı” (kök neden).
Uygulanan düzeltmenin kanıtını da üret (kural hit-count değişimi, allow/deny paterni, log/flow normalleşmesi).

Aynı raporda iki seviye

Yönetici özeti

Risk seviyesi, etkilenen iş servisi, kesinti/sızıntı etkisi, öncelik, öngörülen efor.

Teknik ek

Zaman çizelgesi, kanıt dosyaları, policy snapshot, doğrulama çıktıları, hash listesi.

12.6 HOW-TO: Envanter → Risk Matrisi → Rapor Zinciri

Bu HOW-TO (özet), teknik sinyali “kurumun yönettiği risk”e bağlar: envanter doğruluğu → risk matrisi (olasılık/etki + kontrol boşluğu) → rapor zinciri (kanıtlı karar). Ayrıntılı adımlar 12.8 bölümündedir.

1EnvanterÇoklu kaynak · yaşayan tablo

2Risk matrisiEtki · maruziyet · kontrol boşluğu

3Rapor zinciriBulgu → öncelik → CAPA

Etki / risk

Envanter yanlışsa risk matrisi yanlış; risk matrisi yanlışsa öncelik yanlış olur.
Zincir kırılırsa (kanıt yok / rollback yok / değişiklik kaydı yok) operasyon güveni kaybolur.

Tespit sinyali / kanıt

Envanter kanıtları (CMDB/DNS/DHCP/NAC) + telemetri (flow/log) + doğrulama çıktısı birlikte bulunur.

Savunma kontrolü / düzeltme yaklaşımı

Zinciri standardize et: aynı şablon, aynı isimlendirme, aynı bütünlük yaklaşımı.
Rollback’i zincirin parçası yap: yanlış pozitif her zaman mümkündür.

Not: Tam adım adım runbook için 12.8’e geç; burada zincirin “ne olduğunu” netleştirmek yeterli.

12.7 Komut & Araç Okuryazarlığı (Doğrulama ve Kanıt) — White-Hat

Aşağıdaki komutlar yalnızca denetim/okuma, tekil hedef/tekil servis doğrulaması ve kanıt üretimi içindir. Geniş aralık tarama/hedef bulma/istismar/bypass “how-to” yoktur. Örnek IP ve alan adları uydurmadır (dokümantasyon blokları).

1 · Envanter/görünürlük snapshot’ı (uç nokta perspektifi)

Windows (PowerShell)

A) Ağ arayüzleri ve IP konfigürasyonu (kanıt)

Get-NetIPConfiguration | Out-File .\evidence\w_ipconfig.txt -Encoding UTF8

Amaç: O anki ağ konfigürasyonunu kanıta almak
Beklenen çıktı türü: Metin dosyası
Yorum ipucu: DNS sunucuları, varsayılan ağ geçidi, beklenmeyen interface
Güvenli sınır: Yerel okuma

B) Bağlantılar ve dinleyen portlar (kanıt)

Get-NetTCPConnection |

Sort-Object -Property State,LocalPort,RemoteAddress,RemotePort |

Out-File .\evidence\w_tcp_connections.txt -Encoding UTF8

Amaç: Anlık bağlantı gerçekliğini belgelemek
Beklenen çıktı: Metin dosyası
Yorum ipucu: Beklenmeyen RemoteAddress/RemotePort tekrarları, kısa oturum dalgaları
Güvenli sınır: Yerel okuma

C) ARP/komşu önbelleği (envanter ipucu)

arp -a > .\evidence\w_arp_cache.txt

Amaç: Yerel segmentte görülen komşuları “ipucu” olarak kaydetmek
Beklenen çıktı: Metin dosyası
Yorum ipucu: Aynı MAC’in farklı IP’lerde görünmesi, “yeni” komşular
Güvenli sınır: Yerel okuma

D) Windows’ta kısa süreli paket yakalama (kanıt — yerleşik)

netsh trace start capture=yes tracefile=.\evidence\nettrace.etl maxsize=50

# 60–120 sn gözlemle

netsh trace stop

Amaç: Kısa süreli ağ izi almak (PCAP değil ETL; kurum içi dönüştürme akışı olabilir)
Beklenen çıktı: .etl dosyası
Yorum ipucu: Zaman penceresini not et; gereksiz uzun yakalama yapma
Güvenli sınır: Do not harm; minimizasyon; yetkili ortam

Linux

A) Arayüz/rota snapshot (kanıt)

ip addr show > ./evidence/l_ip_addr.txt

ip route show > ./evidence/l_ip_route.txt

Amaç: Ağ kimliği ve rota gerçekliğini belgelemek
Beklenen çıktı: Metin dosyaları
Yorum ipucu: Default route değişimi, beklenmeyen ek rotalar
Güvenli sınır: Yerel okuma

B) Bağlantılar (kanıt)

ss -tuna > ./evidence/l_ss_tuna.txt

Amaç: Aktif oturumları kanıta almak
Beklenen çıktı: Metin dosyası
Yorum ipucu: Periyodik uzak hedefler, kısa ömürlü oturum paterni
Güvenli sınır: Yerel okuma

C) Komşu tablosu (envanter ipucu)

ip neigh show > ./evidence/l_ip_neigh.txt

Amaç: Yerel segmentte görülen komşuları kaydetmek
Beklenen çıktı: Metin dosyası
Yorum ipucu: REACHABLE/STALE dalgalanması, yeni MAC’ler
Güvenli sınır: Yerel okuma

macOS

A) Arayüz/rota snapshot (kanıt)

ifconfig > ./evidence/m_ifconfig.txt

netstat -rn > ./evidence/m_routes.txt

Amaç: Ağ konfigürasyon gerçekliğini belgelemek
Beklenen çıktı: Metin dosyaları
Yorum ipucu: Varsayılan rota, interface değişimi
Güvenli sınır: Yerel okuma

B) Komşu/ARP (envanter ipucu)

arp -a > ./evidence/m_arp_cache.txt

Amaç: Yerel segment komşu ipuçlarını kaydetmek
Beklenen çıktı: Metin dosyası
Yorum ipucu: Beklenmeyen yeni cihaz izleri
Güvenli sınır: Yerel okuma

2 · Tekil servis doğrulaması (tarama değil)

Windows (PowerShell)

Test-NetConnection -ComputerName 198.51.100.10 -Port 443

Amaç: Tek bir hedefte tek bir servisin erişilebilirliğini doğrulamak
Beklenen çıktı: TcpTestSucceeded True/False
Yorum ipucu: False ise “policy mi, servis mi?” için ikinci kanıt ara (FW log + servis log)
Güvenli sınır: Tek hedef + tek port

Linux / macOS — TLS ve HTTP başlığı

TLS sertifika zinciri (kanıt)

openssl s_client -connect 198.51.100.10:443 -servername example.net -showcerts < /dev/null \
  > ./evidence/tls_sclient_198_51_100_10_443.txt

Amaç: Sertifika zinciri/validity bilgisini kanıta almak
Beklenen çıktı: Metin dosyası
Yorum ipucu: Validity tarihleri, issuer/subject, handshake hatası metni
Güvenli sınır: Tek hedef + tek servis; istismar yok

HTTP başlıkları — curl (varsa; kanıt)

curl -I https://example.net > ./evidence/http_headers_example_net.txt

Amaç: Uygulama/servis başlıklarını (kanıt) almak
Beklenen çıktı: Metin dosyası
Yorum ipucu: Beklenmeyen yönlendirme, TLS hatası, header tutarsızlığı
Güvenli sınır: Tek hedef; düşük yoğunluk

3 · PCAP üretimi ve Wireshark okuryazarlığı (kanıt triangülasyonu)

Yakalama ve okuma

tcpdump — kısa, minimize pcap

sudo tcpdump -i eth0 -w ./evidence/triage_slice_60s.pcap -G 60 -W 1 -s 128

Amaç: 60 saniyelik kanıt dilimi almak (mümkünse SPAN/TAP üzerinden)
Beklenen çıktı: PCAP
Yorum ipucu: Süreyi kısa tut; yalnız gerekli zaman penceresi
Güvenli sınır: Do not harm; minimizasyon; yetkili ortam

Wireshark — “yakala / oku / kanıta çevir”

Nasıl yakalarım?

Zaman penceresini netleştir (T0–T0+60s)

Üretimde ring buffer kullan (dosya döngüsü)

Mümkünse SPAN/TAP ile “gözlem” (uç noktayı yormadan)

Nasıl okurum?

Statistics → Endpoints/Conversations: kim-kiminle, oturum sayısı, hacim

Analyze → Expert Information: retransmission/reset/handshake anomali sinyalleri

Statistics → Protocol Hierarchy: protokol dağılımı sapması

Follow Stream: yalnızca gerekli teknik bağlam için; gereksiz içerik incelemesi yapma (minimizasyon)

Nasıl kanıta çeviririm?

Endpoints/Conversations ekranı + zaman penceresi notu

Gözlem–yorum ayrımı: “şu akış görüldü” (kanıt) vs “veri kaçırdı” (yorum)

PCAP hash + dosya adı + kim aldı kaydı

Örnek display filter (savunma okuryazarlığı)

ip.src == 192.0.2.30 && tcp.port == 443
dns.flags.response == 0
tcp.analysis.retransmission

4 · Kanıt bütünlüğü (hash) ve paketleme

Windows (PowerShell)

Get-FileHash .\evidence\triage_slice_60s.pcap -Algorithm SHA256 |
  Out-File .\evidence\hashes_sha256.txt -Encoding UTF8

Amaç: Kanıt bütünlüğü
Beklenen çıktı: Hash kaydı
Yorum ipucu: Hash + dosya adı + zaman damgası birlikte rapora girer
Güvenli sınır: Yerel

Linux

sha256sum ./evidence/* > ./evidence/hashes_sha256.txt
tar -czf evidence_bundle.tar.gz ./evidence

Amaç: Kanıt setini bütünlükle paketlemek
Beklenen çıktı: Hash listesi + arşiv
Yorum ipucu: Önce hash, sonra arşiv
Güvenli sınır: Yerel

macOS

shasum -a 256 ./evidence/* > ./evidence/hashes_sha256.txt

Amaç: Kanıt bütünlüğü
Beklenen çıktı: Hash listesi
Yorum ipucu: Dosya listesiyle birlikte “Kanıt” bölümüne ekle
Güvenli sınır: Yerel

Dikkat: Kanıt paketleme “paylaşım” değildir. Erişim kurum politikası ve yetkiyle sınırlıdır; minimizasyon esastır.

12.8 HOW-TO: Envanter → Risk Matrisi → Rapor Zinciri

Bu bölüm, 12.6’daki zinciri adım adım açar: hazırlıktan rollback’e kadar tam operasyonel akış. Özet kart için 12.6’ya; kontrol listesi için buraya bakın.

1HazırlıkYetki · başarı kriteri

2UygulamaEnvanter çıkarımı

3DoğrulamaGüvenli tekil test

4KanıtPaketleme · hash

5Risk matrisiÖncelik şablonu

6RaporB → E → Ö → K

7RollbackGeri al · tuning

1 · Hazırlık

1.Yetki & kapsam doğrulama: kapsam içi varlıklar, zaman penceresi, iletişim kanalı.

2.Başarı kriteri: “hangi sinyal nerede görülecek, hangi kanıt rapora girecek?”

3.Veri kaynakları: en az FW log + flow özeti + sistem/uygulama logu; gerekiyorsa kısa pcap.

4.Kanıt standardı: isimlendirme, zaman senkron notu, hash zorunluluğu.

5.Rollback planı: simülasyon/ doğrulama üretimi etkilerse geri alma.

2 · Uygulama (envanter çıkarımı)

1.Otoritatif envanter çek: CMDB/DNS/DHCP/NAC (salt-okuma) ile varlık/rol.

2.Telemetri ile çapraz doğrula: flow/log ile “gerçek konuşma”yı teyit et.

3.Kontrol yüzeyini bağla: ilgili FW/ACL kuralı, proxy policy, segment/zone eşleşmesi.

4.Shadow IT işaretle: envanterde rol/sahip yoksa “etiketsiz” sınıfına al; doğrulama kuyruğuna ekle.

3 · Doğrulama (güvenli tekil doğrulama)

1.Sınıflandır: CVE mi, misconfig mi, exposure mı?

2.En düşük riskli doğrulama: önce config/policy/sertifika kanıtı, sonra tekil bağlantı testi.

3.Karşı kanıt ara: “Bu bulguyu ne çürütür?” (kural hit almıyor, log kaynağı yanlış, saat kayması).

4.Belirsizliği not et: kanıt gücü (yüksek/orta/düşük) ve alternatif açıklamalar.

4 · Kanıt paketleme

1.Log/flow/pcap kesitlerini zaman pencereli ayıkla.

2.Dosya listesi + SHA-256 hash üret.

3.“Kim aldı / nereden aldı / saat” kaydını ekle.

4.Kanıtı arşivle ve bulgu kaydıyla iliştir.

5 · Risk matrisi üretimi (pratik şablon)

Varlık kritikliği (İş etkisi): düşük/orta/yüksek
Maruziyet: yanlış segment/dışa açık/egress genişliği
Kontrol kapsaması: log/flow/IDS görünürlüğü var mı?
Düzeltme eforu: hızlı kazanım mı, proje mi?

Örnek çıktı (risk matrisi satırı — şablon)

Bulgu ID	Varlık	Sınıf	Kritiklik	Maruziyet	Kontrol boşluğu	Öncelik	Hızlı aksiyon	Kalıcı aksiyon
INV-2026-0142	198.51.100.8 (etiketsiz)	exposure	yüksek	SSH dış segmente açık	NDR yok · CMDB boş	P2	geçici: kural daralt	envanter + segment düzelt

6 · Rapor zinciri (Bulgu → Etki → Öneri → Kanıt)

Bulgu: ölçülebilir tek cümle
Etki: iş + operasyon + güvenlik
Öneri: hemen + kalıcı
Kanıt: dosya listesi + hash + zaman penceresi + kaynak sistem

7 · Geri dönüş / rollback

Geçici değişiklik yaptıysan geri al, “önceki durum” kanıtını da ekle.
Yanlış pozitifse: alarm tuning + baseline güncelle.
Doğru pozitifse: değişiklik yönetimiyle kalıcı planı başlat.

Hatırlatma: Zincirin her halkasında kanıt ve rollback birlikte düşünülür; aksi halde “çözdük” sandığı halde öncelik ve güven yanlış kalır.

12.9 Operasyonel Senaryo (izinli/uydurma): “Hayalet Yönetim Paneli”

Belirti

Flow’da 203.0.113.22’den iç ağda beklenmeyen 8080/TCP; CMDB’de “Kullanıcı İstemcisi”, trafik paterni servis arayüzünü çağrıştırıyor.

Hipotezler

(1) Shadow IT / envanter drift (2) Eski CMDB etiketi (3) NAT/proxy kaynaklı görünürlük yanılsaması.

Toplanacak kanıt

Flow özeti: 203.0.113.22 ↔ hedef(ler) ↔ 8080 oturum sayısı/sıklığı
FW/proxy log: ilgili kural hit’leri, allow/deny satırları
İstemci snapshot: bağlantılar/dinleyen portlar (yerel okuma)
Gerekirse kısa pcap dilimi: teknik doğrulama (minimize)
Envanter kanıtları: CMDB + DHCP/DNS/NAC çapraz doğrulama

Analiz (özet)

Envanter çapraz doğrulama: DHCP/NAC ile MAC/port; CMDB rolü ile karşılaştır.
Karşı kanıt: Flow’da 8080 görünüp uçta dinleyen yoksa NAT/etiketleme şüphesi.
Güvenli tekil doğrulama: yerelde dinleyen portlar kanıtta; varsa yalnızca erişilebilirlik/başlık düzeyi, konfig değişikliği yok.
Kontrol: Arayüzün olması gereken segment, kimlik zorunluluğu, egress/segment tutarlılığı.

Karar

Envanter drift + servis izi doğrulanıyorsa: Shadow IT bulgusu olarak ele al; risk matrisiyle önceliklendir.
Flow yanlış etiketleniyorsa: telemetri/etiketleme düzeltmesi başlat; görünürlük boşluğunu raporla.

Rapor (Bulgu → Etki → Öneri → Kanıt)

Bulgu: 203.0.113.22 varlığında CMDB rolü ile uyumsuz şekilde 8080/TCP servis trafiği gözlendi; flow + uç nokta snapshot ile doğrulandı.
Etki: Yetkisiz yönetim arayüzleri, segmentasyon ve erişim kontrolü boşluğu doğurabilir; görünürlük ve değişiklik yönetimi zayıflar.
Öneri: (Hemen) servisi izinli modele çek (erişimi daralt, kimlik doğrulama zorunlu, uygun segmente taşıma planı) + (Kalıcı) yaşayan envanter/CMDB drift kontrolünü rutinleştir, egress/segment politikalarını role göre standardize et.
Kanıt: flow özeti, ilgili FW/proxy log kesiti, uç nokta bağlantı/dinleme snapshot dosyaları, hash listesi.

Terimler sözlüğü

Terim Türkçe karşılığı / açıklama

Yetkili keşif (Reconnaissance) İzinli kapsam içinde envanter ve görünürlük üretme disiplini

Shadow IT IT’nin bilgisi/kontrolü dışında ortaya çıkan sistem/yazılım/servisler

False Positive Güvenlik aracının zararsız durumu riskli diye işaretlemesi

Misconfiguration Yanlış yapılandırma (policy/segment/TLS/egress vb.)

Exposure Gereksiz açık yüzey/maruziyet (yanlış segmente/dışa açık servis vb.)

Purple team Savunma tespit/yanıt kabiliyetini ölçme ve iyileştirme yaklaşımı

Triangülasyon Aynı bulguyu log + flow + (gerekirse) pcap ile çapraz doğrulama

Flow Özet trafik kaydı (kim kiminle konuştu, ne kadar, ne sıklıkta)

PCAP Paket yakalama verisi (kısa dilim, minimizasyon)

Kanıt bütünlüğü Hash ve izlenebilir kayıtla kanıtın değişmediğini göstermek

Rollback Geçici aksiyonları geri alma ve önceki durumu kanıtlama

Kendini Değerlendir

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

Aşağıdakilerden hangisi “yetkili keşif” çıktısının en doğru tanımıdır?

A) IP aralığında kapsamlı servis keşfi yapıp tüm açık portları listelemek

B) CMDB’de kayıtlı cihazları silip yeniden otomatik kaydetmek

C) Envanter doğruluğu ve görünürlük için çoklu veri kaynağını birleştiren, kanıtlanabilir bir envanter üretmek

D) Yalnızca PCAP alıp ne olduğunu sonradan anlamaya çalışmak

E) Sadece firewall kural sayısını raporlamak

Doğru: C
Gerekçe: Modül hedefi “harita çıkarmak + kanıtlanabilir görünürlük”tir. A gereksiz agresif olabilir; B değişiklik yönetimini bozar; D tek kaynağa bağımlıdır; E bağlam üretmez.

“Açık port ≠ zafiyet” ifadesinin doğru yorumu hangisidir?

A) Açık portlar her zaman kapatılmalıdır

B) Açık port varsa mutlaka CVE vardır

C) Risk, portun arkasındaki servis/konfigürasyon ve maruziyet bağlamıyla oluşur

D) Port açık olsa bile log tutmak gereksizdir

E) Zafiyet yalnızca dış ağda mümkündür

Doğru: C
Gerekçe: Port “yüzey”dir; risk sınıflandırması servis ve konfige bağlıdır. Diğer şıklar ya aşırı genelleme ya da görünürlük karşıtıdır.

Bir otomatik tarayıcı “kritik” bulgu üretti. Güvenli doğrulama için en doğru ilk adım hangisidir?

A) Bulguyu kanıtlamak için saldırı otomasyonu çalıştırmak

B) Önce konfig/policy/sertifika gibi düşük riskli kanıtları toplayıp, tekil doğrulama planı çıkarmak

C) Aynı bulguyu tekrar tekrar üretimde denemek

D) Hemen tüm segmentte değişiklik yapmak

E) PCAP’ı saatlerce yakalayıp sonra incelemek

Doğru: B
Gerekçe: “En az riskli yol” ve minimizasyon esastır. A ve C suistimal/kesinti riski; D kapsamlı değişiklik; E gereksiz veri toplama.

“İki bağımsız kanıt” kuralı en iyi hangi çiftle sağlanır?

A) İki farklı ekran görüntüsü

B) Aynı log kaynağından iki satır

C) Flow özeti + ilgili kontrol logu (FW/proxy)

D) PCAP’ın iki kopyası

E) Kullanıcı beyanı + e-posta

Doğru: C
Gerekçe: Farklı telemetri türleri (akış + kontrol logu) çapraz doğrulama sağlar. Diğerleri ya aynı kaynağın tekrarı ya da teknik kanıt değildir.

Purple team simülasyonunda “ölçüm” aşağıdakilerden hangisini doğrudan hedefler?

A) Maksimum etkiyi yaratmayı

B) Prevention/Detection/Visibility çıktılarının oluşup oluşmadığını kanıtlamayı

C) Varlık sayısını artırmayı

D) Gizli kalmayı

E) Üretimde kalıcı değişiklik yapmayı

Doğru: B
Gerekçe: Purple team’in amacı savunmayı ölçmek ve iyileştirmektir; zarar verme/gizlilik değil.

Flow–Log–PCAP triangülasyonunda “en kritik disiplin” hangisidir?

A) Tüm trafiği sürekli yakalamak

B) Zaman penceresini hizalamak ve kanıt–yorum ayrımını korumak

C) Sadece PCAP’a güvenmek

D) Sadece yönetici özeti yazmak

E) Yalnızca alarm skoruna bakmak

Doğru: B
Gerekçe: Aynı olayı aynı zaman penceresinde bağlamak ve yorumdan kaçınmak denetlenebilirliği sağlar.

Aşağıdakilerden hangisi Shadow IT riskinin en doğru operasyonel sonucudur?

A) Daha az log oluşması

B) Kontrol dışı varlığın yamalanamaması/izlenememesi nedeniyle kör nokta oluşması

C) Her zaman dış saldırı anlamına gelmesi

D) Sadece kablosuz ağlarda görülmesi

E) Sadece yazılım lisans problemi olması

Doğru: B
Gerekçe: Shadow IT’nin temel riski kontrol ve görünürlük kaybıdır. C/D/E dar ve yanlış genellemelerdir.

Bir bulgu raporunda aşağıdakilerden hangisi “Bulgu” cümlesine en uygundur?

A) “Saldırgan veri çaldı.”

B) “Bu kesinlikle çok tehlikeli.”

C) “2026-02-10 14:00–14:05 aralığında 192.0.2.30’dan 198.51.100.10:443’e periyodik kısa TLS oturumları gözlendi; flow ve FW log ile doğrulandı.”

D) “Bence bu bir APT.”

E) “Bu portu kapatalım.”

Doğru: C
Gerekçe: Ölçülebilir, zamanlı, kanıta bağlı. A/B/D yorum; E öneridir.

Kanıt paketlemede hash’in asıl rolü hangisidir?

A) Kanıtı daha okunur yapmak

B) Kanıtın gizli olduğunu göstermek

C) Kanıtın sonradan değişmediğini doğrulamak (bütünlük)

D) Kanıtı otomatik analiz etmek

E) Kanıtı daha hızlı iletmek

Doğru: C
Gerekçe: Hash bütünlük doğrulamasıdır; gizlilik/okunurluk/iletim hızı farklı mekanizmalardır.

“Risk matrisi” üretirken en doğru yaklaşım hangisidir?

A) Sadece CVE skoruna göre sıralamak

B) Varlık kritikliği + maruziyet + kontrol boşluğu + düzeltme eforunu birlikte değerlendirmek

C) Sadece en çok alarm veren sistemi seçmek

D) Sadece dışa açıkları önemsemek

E) Her şeyi aynı öncelikte ele almak

Doğru: B
Gerekçe: Operasyonel öncelik; iş etkisi ve kontrol kapsamasıyla birlikte değerlendirilir. Tek metrik yaklaşımı körleştirir.

Kapanış: Bu modülde neler kazandık?

Yetkili keşfi “hedef arama” değil, kanıtlanabilir envanter + görünürlük üretimi olarak konumlandırdık.
Zafiyet okuryazarlığında CVE/misconfig/exposure ayrımını ve “açık port ≠ zafiyet” refleksini kurduk.
Güvenli doğrulamada “en az riskli yol”, “tekil doğrulama” ve “iki bağımsız kanıt” disiplinini netleştirdik.
Purple team simülasyonlarını prevention/detection/visibility ölçümü ve tuning döngüsüne bağladık.
Flow–log–pcap triangülasyonu ve kanıt–yorum ayrımıyla raporu denetlenebilir hale getirdik.
Envanter → risk matrisi → rapor zinciri ile teknik sinyali kurumsal karara dönüştürdük.