Hafta 12 — Güvenlik Sertifikasyonları ve Sızma Testi Planlaması¶

Sunumun içine tıklayıp ok tuşlarıyla ilerleyin; tam ekran için sunumun sağ altındaki düğmeyi ya da yukarıdaki "Sunumu tam ekran aç" bağlantısını kullanın.

# Windows (PowerShell)
.\build.ps1
cd week-12\01-birim-test
.\bin\windows\birim_test.exe
cd ..\02-saldiri-potansiyeli
.\bin\windows\saldiri_potansiyeli.exe

# WSL / Linux
./build.sh
cd week-12/01-birim-test && ./bin/linux/birim_test
cd ../02-saldiri-potansiyeli && ./bin/linux/saldiri_potansiyeli

0. Başlamadan önce¶

Bu bölüm haftaya hazırlık içindir. Önce bu haftanın dayandığı önceki konuları kısaca hatırlatır; sonra bu haftanın kavramlarını birer cümleyle tanımlayıp her birini ayrıntılı anlatıldığı bölüme bağlar.

Önceki haftalardan gelenler¶

• Zafiyet (vulnerability) — bir sistemde kötüye kullanılabilecek zayıf bir nokta, ör. sınır denetimsiz bir tampon (Hafta 1, §1). Bu hafta bu kavramı bulgu ve risk kavramlarından tek tek ayırıyoruz ve üçünü bağımsız bir değerlendirmenin diliyle yeniden kuruyoruz (§0 sonu, §6).
• Kerckhoffs ilkesi — bir sistemin güvenliğinin tasarımın gizli kalmasına değil, yalnızca anahtarın gizli kalmasına dayanması gerektiği ilke (Hafta 3, §2). Bu hafta bu ilke, değerlendiricinin "saldırgan sistemi tam bilir" varsayımının ve beyaz kutu çalışma biçiminin gerekçesi olarak geri dönüyor (§0 sonu).
• Statik ve dinamik analiz — kodu çalıştırmadan (statik) ya da çalıştırırken sanitizer'larla (dinamik) hata arama yöntemleri (Hafta 4, §9; dinamik taraf için §10). Bu hafta bu ikisini bağımsız değerlendirmenin resmi adlarıyla SAST ve DAST olarak kullanıp zafiyet değerlendirme sırasına yerleştiriyoruz (§3).
• Fuzzing — bir programa beklenmeyen/rastgele girdiler vererek çökme ya da bozulma arama tekniği (Hafta 4, §11). Bu hafta fuzzing'i zafiyet değerlendirme sırasının dördüncü adımı olarak, süresi ve ulaştığı kod kapsamıyla birlikte raporlanması gereken bir yöntem olarak görüyoruz (§3).
• CVSS — bir zafiyetin etkisini standart bir puanla (0–10) ifade eden Ortak Zafiyet Puanlama Sistemi (Hafta 2, §15). Bu hafta CVSS'i saldırı potansiyeliyle karşılaştırıp ikisinin neden farklı sorulara cevap verdiğini görüyoruz (§5).

Bu haftanın kavram haritası¶

Risk kavramını biraz daha açalım: risk, bir zafiyetin sömürülme olasılığı ile sömürüldüğünde oluşacak etkinin birlikte değerlendirilmesidir — kabaca "ne kadar olası × ne kadar kötü". Her zafiyet aynı riski taşımaz: sömürülmesi neredeyse imkânsızsa (örn. kilitli bir odadaki, ağa hiç bağlı olmayan bir sunucu) risk düşüktür; aynı zafiyet internete açık bir sunucuda ise risk yüksektir — zafiyet aynı, risk farklı. Bütün önlemlerden sonra hâlâ kapatılamayan risk kalan risk (residual risk) olarak adlandırılır; iyi bir rapor bunu açıkça yazar, saklamaz (§6'da örneğini göreceğiz). Kısacası: zafiyet teknik bir zayıflıktır, bulgu bu zayıflığın değerlendirmede kanıtla belgelenmesidir, risk ise "bu zayıflık gerçekten ne kadar tehlikeli" sorusuna verilen bağlamsal yanıttır.

Bu üç terimi ve beyaz kutu/kara kutu ayrımını, aşağıda tek bir örnek ve bir karşılaştırma tablosuyla somutlaştırıyoruz; bu iki parça, bu haftanın kavramlarını gövdeye taşımadan önceki son bağlayıcı adımdır.

Terimleri birbirinden ayırmak: uçtan uca küçük bir örnek¶

Yukarıdaki tanımlar tek tek anlamlı ama aralarındaki fark, tek bir örnek üzerinde görülmeden soyut kalır. Aşağıdaki sentetik fonksiyonu düşünün:

int oturum_ac(const char *kullanici, const char *sifre)
{
    char sorgu[256];
    /* HATA: kullanici ve sifre dogrudan sorguya ekleniyor */
    sprintf(sorgu, "SELECT * FROM kullanicilar WHERE ad='%s' AND sifre='%s'",
            kullanici, sifre);
    return veritabani_calistir(sorgu);   /* 1 = giris basarili */
}

Bu fonksiyonda kullanici alanına ' OR '1'='1 yazan biri, şifre bilmeden giriş yapabilir (klasik SQL enjeksiyonu, CWE-89). Şimdi her yöntemin bu tek hatayı nasıl (ve ne kadar) yakaladığını satır satır izleyelim — bu, bölüm 3'teki "hangi yöntem ne bulur" sorusunun ilk somut örneğidir:

Terimleri şimdi bu örnek üzerinden yerleştirelim:

• Zafiyet: sprintf ile parametresiz SQL sorgusu kurmak — teknik zayıf nokta.
• Bulgu: değerlendiricinin bunu yazılı olarak belgelemesi: "T-14: oturum_ac fonksiyonu SQL enjeksiyonuna açık, kanıt: ekran görüntüsü, CWE-89."
• Risk: bu uygulama internete açıksa ve arkasında gerçek kullanıcı verisi varsa risk yüksektir (olasılık yüksek × etki yüksek); yalnız kapalı bir test ağında çalışan bir prototipse aynı zafiyetin riski daha düşük değerlendirilebilir.
• Öneri: parametreli sorgu (prepared statement) kullanımı.

Standart mı, sertifika mı? Sık karıştırılan bir çift¶

• Standart, bir kuraldır: "anahtar türetme böyle yapılmalı" der. Standardın kendisi hiçbir ürünü onaylamaz; yalnızca ölçütü tanımlar.
• Sertifika, bir ürünün ya da kurumun o kuralı karşıladığının belgesidir. Standart olmadan sertifika olmaz; ama bir standardı okumak (ya da ona "uygun tasarlamak") kendi başına sertifika almak anlamına gelmez — bağımsız bir doğrulama (değerlendirme) gerekir.

Beyaz kutu neden tercih edilir? Kısa bir karşılaştırma¶

İlerideki bölümlerde "değerlendirici, saldırganın sistemi tam bildiğini varsayar" cümlesini sık göreceğiz — bu varsayımın kaynağı Hafta 3'ten hatırladığımız Kerckhoffs ilkesi**dir: bir sistemin güvenliği tasarımın gizli kalmasına değil, yalnızca anahtarın gizli kalmasına dayanmalıdır; "algoritmamızı kimse bilmiyor, o yüzden güvenliyiz" savunması geçersizdir. Değerlendiricinin **beyaz kutu çalışması (aşağıda) tam olarak bu ilkenin doğal sonucudur: madem gerçek bir saldırgan er ya da geç tasarımı öğrenebilir, değerlendirici de baştan her şeyi görsün.

Bütün terimleri tek bir cümlede birleştirelim¶

Şimdiye kadar tek tek tanımladığımız terimleri, gerçek bir sürecin tek bir akışında görelim — bu, haftanın geri kalanının tek cümlelik özetidir:

Bir standart hangi gereksinimlerin karşılanması gerektiğini söyler; bir değerlendirme laboratuvarı, beyaz kutu erişimle (Kerckhoffs ilkesi gereği, saldırganın her şeyi bildiğini varsayarak) ürünü inceler; kod incelemesi, SAST, DAST, fuzzing ve sızma testi ile zafiyetleri bulur; her zafiyeti kanıtla bir bulguya dönüştürür; her bulguyu saldırı potansiyeli ve CVSS ile derecelendirir; geliştirici düzeltme yapınca laboratuvar yalnız değişeni delta değerlendirmeyle yeniden inceler; sonunda bir sertifikasyon otoritesi, belirli bir TOE kimliği için sertifikayı verir.

Bu tek paragrafı okuyup her terimi tanıyabiliyorsanız, bölüm 1'den 9'a kadar göreceğimiz her şeyin iskeletini zaten kurmuşsunuz demektir; geri kalan bölümler bu iskeletin etini dolduracak. Şimdi: neden bağımsız değerlendirme?

1. Neden bağımsız değerlendirme?¶

Bir yazılımı yazan ekip, onun en iyi test edicisi değildir: tasarım varsayımlarını paylaşır, "bu nasılsa olmaz" dediği yolları hiç denemez. Bu yüzden ödeme, kimlik, sağlık ve kamu gibi alanlarda ürünler, bağımsız bir laboratuvarın değerlendirmesinden geçer. Değerlendirmenin sonunda bir sertifika (ya da onay) verilir; sertifika "bu ürün kırılamaz" demez, "bu ürün şu standardın şu gereksinimlerini, şu saldırgan modeline karşı, şu tarihte karşılıyordu" der.

Bu dersin projesini baştan beri "bir sertifikasyondan geçecekmiş gibi" tasarladık. Bu hafta o sürecin kendisini, bir değerlendiricinin gözünden, adım adım işliyoruz.

Standartlar ve sertifikasyon manzarası¶

Sertifikasyon ne söyler, ne söylemez?¶

Bir sertifika okuyucusunun en sık yaptığı hata, "sertifikalı" sözcüğünü "kırılamaz" ile eş tutmaktır. Sertifika aslında dört şeyi birlikte söyler; dördünden biri eksikse cümle anlamsızlaşır:

1. Hangi ürün — TOE'nin tam kimliği: sürüm + ikili dosya + kaynak kod + özet değeri (bölüm 2'de göreceğiz).
2. Hangi standarda göre — ör. Ortak Kriterler, EMVCo, PCI.
3. Hangi saldırgan modeline karşı — ör. "fiziksel erişimi olmayan, ağ üzerinden saldıran orta düzey saldırgan".
4. Hangi tarihte — yazılım güncellenince sertifika o eski sürüm için geçerliliğini korur; yeni sürüm ya delta değerlendirmeden geçmeli ya da sertifikasız sayılmalıdır.

Neden geliştirici kendi ürününü onaylayamaz?¶

Bu bir yetenek sorunu değil, bir bakış açısı sorunudur. Bir ürünü yazan ekip üç önyargıyı aynı anda taşır:

• Tasarım varsayımlarını paylaşır — "kullanıcı bu alana asla 300 karakter girmez" diyen geliştirici, testini de bu varsayıma göre yazar; sınır dışı girdiyi hiç denemez.
• "Buraya kimse dokunmaz" dediği yollara hiç bakmaz — çünkü kendi zihin modelinde o yol zaten kapalıdır.
• Kendi kodunu eleştirmekte isteksizdir — zaman baskısı altında "büyük ihtimalle güvenlidir" cümlesi bir kanıt değildir ama insan doğası buna eğilimlidir.

Bağımsız bir laboratuvar bu üç önyargıdan hiçbirini paylaşmaz: geliştiricinin belgesini okur ama sınırlarını sorgular, "kimse dokunmaz" dediği yolu ilk kontrol ettiği yer yapar ve ürünün kendi çıkarına bakmadığı için "muhtemelen güvenli" cümlesini kabul etmez — kanıt ister.

Aynı ürün, farklı şemalarda farklı testler: kısa bir örnek¶

Aynı mobil ödeme uygulamasının farklı hedef pazarlara göre farklı değerlendirmelerden geçmesi gerekebilir:

• Uygulama bir bankaya satılacaksa: bankanın bilgi güvenliği yönetim sistemi muhtemelen ISO/IEC 27001 kapsamındadır — ama bu, uygulamanın kendisini değil, bankanın süreçlerini sertifikalar.
• Uygulama kart verisi işliyorsa: PCI DSS (kurum) ve/veya PCI MPoC/SSF (yazılım) kapsamına girer — yazılımın kart verisini nasıl işlediği, sakladığı, ilettiği test edilir.
• Uygulama bir ödeme şemasının (ör. bir kart ağının) markasını taşıyacaksa: EMVCo değerlendirmesinden geçmesi gerekir — çip/yazılım tabanlı ödeme akışlarının güvenliği, laboratuvar sızma testiyle sınanır.
• Uygulama genel bir mobil güvenlik iddiası taşıyorsa: OWASP MASVS düzeyine göre test edilebilir — bu bir sertifika değil ama tanınmış bir test çerçevesidir.

Aynı kod tabanı, dört farklı mercekten dört farklı soruyla sınanır. Projenizde "hangi standarda yakınız" sorusunun cevabı, S17'deki gereksinim şablonunun hangi sütunlarla doldurulacağını belirler.

Sertifikasyonun maliyeti: neden her ürün sertifikalanmaz?¶

Bağımsız değerlendirme ücretsiz değildir — laboratuvar zamanı, uzman mühendis saatleri, bazen özel ekipman gerektirir; süreç haftalar-aylar sürebilir. Bu yüzden her yazılım her standarda göre sertifikalanmaz; bir ekip şu soruyu sorar: "bu sertifikanın maliyeti, sağladığı **güven**e değer mi?"

• Bir bankaya satılacak bir ödeme kütüphanesi için cevap genelde **evet**tir: sertifika olmadan banka o kütüphaneyi hiç almayabilir; sertifikanın maliyeti, kaybedilecek satıştan çok daha küçüktür.
• Bir iç şirket aracı (yalnız kendi çalışanlarının kullandığı, dışarı satılmayan bir uygulama) için tam kapsamlı bir Ortak Kriterler değerlendirmesi genelde orantısızdır; bunun yerine daha hafif bir iç güvenlik incelemesi (kod incelemesi + SAST + temel sızma testi) tercih edilir.

Sertifikasyonun tarihsel itici gücü: neden ortaya çıktı?¶

Bölümün başındaki kısa tarihçeyi bir de "neden" sorusuyla okuyalım — her adım aslında gerçek bir güven krizine cevaptır:

• TCSEC (1985) öncesinde, ABD hükümeti güvenlik iddialarını değerlendirecek ortak bir ölçüt bulamıyordu; her tedarikçi kendi "güvenlidir" tanımını kullanıyordu — karşılaştırma imkânsızdı.
• Ortak Kriterler (1999), ABD/Avrupa/Kanada'nın ayrı ayrı ölçütlerinin (TCSEC/ITSEC/CTCPEC) birbiriyle karşılaştırılamaz olmasının doğurduğu bir sorunu çözmek için birleştirildi — uluslararası ticarette aynı ürünün her ülkede yeniden değerlendirilmesi gerekmesin diye.
• CVE/CWE/CVSS (Hafta 2, §15'te gördüğümüz gibi) 1999→2006 arasında, güvenlik açıklarının isimsiz ve karşılaştırılamaz biçimde raporlanmasının yarattığı kargaşaya cevap olarak doğdu.

Sık sorulan soru: bir sertifika süresiz midir?¶

Zayıf bir öğrencinin çoğu zaman atladığı ama önemli bir nokta: sertifika, "bu ürün sonsuza kadar güvenlidir" demez. Üç ayrı neden yüzünden bir sertifika zamanla geçerliliğini yitirebilir ya da yeniden gözden geçirilmesi gerekebilir:

1. Ürün değişir — yeni bir sürüm çıkar; bölüm 2'deki delta değerlendirme devreye girer, sertifika yeni TOE kimliğine taşınmalıdır.
2. Saldırı teknikleri gelişir — bugün "çoklu uzman, aylar" gerektiren bir saldırı, birkaç yıl sonra ucuz araçlarla "sıradan kullanıcı, bir gün"e düşebilir (bölüm 5'teki puanlama zamanla değişebilir).
3. Standart güncellenir — bir standardın yeni sürümü, eskiden yeterli sayılan bir kontrolü artık yetersiz bulabilir.

2. Değerlendirme süreci: 13 adım¶

Aşağıdaki akış, bir yazılım bileşeninin (ör. bir mobil ödeme kütüphanesi) üçüncü taraf bir laboratuvarda değerlendirilmesinin genelleştirilmiş halidir. Ürün, kurum ve şema adları çıkarılmıştır; adımlar birçok şemada benzerdir.

TOE kimliği: neden "sürüm 3.2.0" yetmez?¶

Az sonra göreceğimiz 13 adımın ilki, bir sürüm numarasından çok daha kesin bir tanım ister. Nedenini bir örnekle görelim: bir ekip "sürüm 3.2.0" der, ama aynı sürüm numarasıyla üç farklı ikili dosya var olabilir — biri hata ayıklama sembolleriyle derlenmiş (debug build), biri optimize edilmiş sürüm derlemesi (release build), biri de bir geliştiricinin yerel makinesinde farklı derleyici bayraklarıyla ürettiği bir kopya. Bunların davranışı (hata ayıklama çıktısı, zamanlama, hatta bazı güvenlik kontrollerinin varlığı) farklı olabilir. Bu yüzden TOE kimliği dört parçadan oluşur (yukarıdaki görsel):

1. Sürüm etiketi — insan okur için (ör. "3.2.0").
2. İkili dosya — hangi derleme (release/debug, hangi mimari: ARM64/x86_64).
3. Kaynak kod — hangi commit/etiket (git tag/commit özeti).
4. Özet değeri (hash) — ikili dosyanın SHA-256'sı; tek bir baytın bile değişip değişmediğini kanıtlar.

Bu görseldeki üç aşamayı adlandıralım: Hazırlık (adım 1–4: TOE, belgeler, şablon, atölye), Değerlendirme (adım 5–9: kod inceleme → zafiyet analizi → sızma testi → işlevsel uygunluk → bulgular), Süreklilik (adım 10–13: etki analizi → delta değerlendirme → ödünleşim/kalan risk → değişiklik yönetimi). Sertifika, Değerlendirme aşamasının sonunda verilir; ama Süreklilik aşaması ürünün ömrü boyunca hiç bitmez.

Adım 2'deki "güvenli kanal" ne demektir?¶

Tablodaki "güvenli bir kanalla teslim edilir" ifadesi boşuna değildir: kaynak kod ve güvenlik kılavuzu, henüz sertifikalanmamış bir ürünün en hassas bilgileridir. Bunları e-posta ekiyle ya da genel bir dosya paylaşım bağlantısıyla göndermek, değerlendirme başlamadan önce ürünün gizliliğini zedeler.

• Şifreli aktarım: dosyalar AEAD (Hafta 3, §2) ile şifrelenip, anahtar ayrı bir kanaldan paylaşılır; ya da uçtan uca şifreli bir kurumsal dosya paylaşım sistemi kullanılır.
• Bütünlük kontrolü: teslim edilen paketin bir özet değeri (hash) ayrıca iletilir; laboratuvar dosyayı aldığında hash'i doğrular — aktarımda bozulma ya da kurcalama olup olmadığını anlamak için (hafta 3'teki AEAD etiket doğrulamasının kurumsal karşılığı).
• Erişim kaydı: kim, ne zaman, hangi dosyayı indirdi kaydı tutulur; bu, kaynak kodun yetkisiz kopyalanmasını sonradan tespit etmeyi sağlar.

Uçtan uca örnek: "GüvenPay Cüzdan SDK v3.2.0" bir laboratuvardan geçiyor¶

Yukarıdaki tablo 13 adımı özetliyor; ama bir tabloyu okumak ile bir süreci yaşamak aynı şey değildir. Aşağıda, tamamen kurgusal bir ürünü ("GüvenPay Cüzdan SDK", sürüm 3.2.0 — bir mobil cüzdan uygulamasının kart saklama ve ödeme kütüphanesi) bu 13 adımdan atlamadan geçiriyoruz. Amaç, her adımda kimin ne yaptığını, hangi belgenin elden ele geçtiğini somut biçimde görmek.

Adım 1 — Değerlendirme hedefi (TOE). GüvenPay ekibi laboratuvara şunu yazar: "Değerlendirilecek ürün: GüvenPay Cüzdan SDK, sürüm 3.2.0, Android ARM64 derlemesi, SHA-256 özet değeri a1b2c3... (1. haftadaki sürüm kimliği disiplini burada geri döner). Kapsam dışı: uygulamayı barındıran mobil işletim sistemi, kullanıcının cihazı." Değerlendirici bu satırı okur okumaz ilk sorusunu sorar: "peki platform güvenilir mi?" Cevap hayırdır — varsayım budur (aşağıda göreceğiz).

Adım 2 — Belgelerin teslimi. GüvenPay, kaynak kodu, API belgesini ve en önemlisi güvenlik kılavuzunu şifreli bir kanalla laboratuvara gönderir. Kılavuzda "kart numarası yalnız AES-256-GCM ile şifreli saklanır" gibi cümleler, her biri bir gereksinim referansıyla yazılmıştır (bkz. hafta 3 AEAD, hafta 10 sürüm imzalama).

Adım 3 — Gereksinim şablonu. Laboratuvar, seçilen standardın (burada varsayım: EMVCo + PCI MPoC karışımı) numaralı gereksinimlerini bir şablona döker: "Gereksinim 4.2 — Kart verisi saklanırken şifrelenmelidir. Durum: GüvenPay 'karşılandı' diyor, kanıt: kılavuz bölüm 3.1, kaynak kod kart_deposu.c satır 40–85." Bu, projenizdeki S17 uyum matrisinin küçük bir örneğidir.

Adım 4 — Atölye. Laboratuvar ve GüvenPay ekibi bir toplantıda (fiziksel ya da çevrimiçi) şablonu birlikte gözden geçirir: "Gereksinim 6.1 (anahtar rotasyonu) için henüz kanıt yok — bunu nasıl kapatacaksınız?" GüvenPay bir belge güncelleme planı sunar.

Adım 5 — Kaynak kod incelemesi. Laboratuvarın iki mühendisi, kart_deposu.c, anahtar_yonetimi.c ve ağ katmanını satır satır okur (beyaz kutu). Bir mühendis, anahtar türetmede sabit bir tuz kullanıldığını fark eder — bu, zafiyet analizi adımına geçmeden ilk bulgu adayı olarak not edilir.

Adım 6 — Zafiyet analizi. Laboratuvar, GüvenPay'in varlık listesini (kart numarası, CVV, oturum anahtarı; bu varlık kavramını Hafta 1, §6'da tanımlamıştık) çıkarır ve her biri için "bu varlık nerede, hangi durumda (bellekte/diskte/ağda) açığa çıkabilir?" sorusunu sorar. Sonuç: bir sızma testi planı (bölüm 7) hazırlanır; sabit tuz bulgusu da plana bir test maddesi olarak eklenir.

Adım 7 — Sızma testi. Plandaki her madde, sekiz başlıklı test kartıyla (bölüm 7) yürütülür. Sabit tuz maddesi için: aynı anahtar türetme fonksiyonu iki farklı cihazda çalıştırılır, aynı anahtarın çıktığı gözlenir (kanıt). Bu bulgu saldırı potansiyeliyle derecelendirilir (bölüm 5) — hedef bilgisi kamuya açık (kaynak koddaki sabit), ekipman standart, süre kısa → düşük saldırı potansiyeli → ciddi bulgu.

Adım 8 — İşlevsel uygunluk. Laboratuvar, standart test paketiyle GüvenPay'in beklenen işlevlerini de sınar: ödeme akışı doğru tutarı mı gönderiyor, hatalı PIN girişinde doğru şekilde mi reddediyor? Bu, güvenlik testinden ayrı ama tamamlayıcı bir adımdır — güvenli ama çalışmayan bir ürün de sertifikalanamaz.

Adım 9 — Bulgular ve düzeltmeler. Laboratuvar raporu: "Bulgu F-03: anahtar türetmede sabit tuz kullanılıyor, kanıt: iki cihazdan aynı anahtar. Öneri: cihaz başına rastgele tuz (Hafta 3, §3'teki CSPRNG kuralı) + KDF." GüvenPay yanıt verir: "Kabul, v3.2.1'de düzeltilecek." Bazı küçük bulgular (ör. "günlük mesajları İngilizce değil") ise "güvenlik sorunu değil, iyi uygulama önerisi" diye kapanır.

Adım 10 — Güvenlik etki analizi. GüvenPay, v3.2.1'i hazırlarken bir belge yazar: "Değişiklik türü: hata düzeltmesi (güvenlik). Etkilenen dosya: anahtar_yonetimi.c. Güvenlik etkisi: anahtar türetme artık cihaz başına rastgele tuz kullanıyor; önceki sürümdeki zayıflık kapatıldı, başka bir varlığı etkilemiyor."

Adım 11 — Delta değerlendirme. Laboratuvar, tüm ürünü baştan incelemez; yalnız anahtar_yonetimi.c dosyasını, etki analizini ve yeni TOE kimliğini (v3.2.1, yeni özet değeri) inceler. Adım 7'deki test tekrarlanır: bu kez iki cihazdan farklı anahtar çıktığı doğrulanır → bulgu kapanır.

Adım 12 — Ödünleşim ve kalan risk. Rapor kalan bir riski açıkça yazar: "Anahtar rotasyon sıklığı yılda birdir; daha sık rotasyon önerilir ama performans maliyeti nedeniyle GüvenPay bu riski kabul ettiğini gerekçeleriyle belgelemiştir." Bu, Hafta 1, §19'daki ödünleşim (trade-off) disiplininin sertifikasyondaki karşılığıdır.

Adım 13 — Değişiklik yönetimi. GüvenPay'in v3.2.1'i yayınlaması, kendi temel çizgisine (baseline) göre sınıflandırılır, onaylanır, test edilir, yayınlanır ve laboratuvarca doğrulanır; bu döngü ürünün hayatı boyunca her sürümde tekrarlanır — sertifika bir kere alınıp unutulan bir belge değil, sürdürülen bir durumdur.

Değerlendiricinin temel tutumu¶

Değerlendirici iki varsayımla çalışır: (1) bütün kaynak koda ve belgelere erişimi vardır (beyaz kutu bağlam) ve (2) ürünün çalıştığı platform güvenilmezdir. Bu yüzden bir korumanın var olması yetmez; ne kadar kolay aşıldığı ölçülür. Tek bir korumayı değil, korumaların birlikte aşılmasının ne kadar sürdüğünü raporlar; iyi tasarlanmış bir üründe saldırgan birkaç korumayı zincirlemek zorunda kalır.

Süreçteki roller: kim kimdir?¶

GüvenPay örneğinde "laboratuvar" ve "GüvenPay ekibi" dedik ama gerçek bir değerlendirmede en az dört ayrı taraf vardır; bunları karıştırmak, özellikle "kim neye karar veriyor" sorusunda kafa karışıklığına yol açar:

Neden bu üç aşama bu sırada? (Hazırlık → Değerlendirme → Süreklilik)¶

13 adımı üç aşamaya ayırmıştık; sıranın neden böyle olduğunu düşünelim — her aşama bir öncekinin üzerine kurulur, atlanamaz:

• Hazırlık önce gelir, çünkü neyin test edileceği (TOE) belirsizse, hiçbir test tekrarlanabilir olmaz. Bir laboratuvar önce "tam olarak neyi inceliyorum?" sorusuna kesin bir cevap ister; bu cevap olmadan kod incelemesine başlamak, hangi dosyanın kapsamda olduğunu bile bilmeden çalışmak demektir.
• Değerlendirme ortada gelir, çünkü hazırlıktaki gereksinim şablonu (adım 3) olmadan "bu bir bulgu mu, yoksa normal mi?" sorusuna cevap verilemez — bulgu, bir gereksinime göre tanımlanır, boşlukta değil.
• Süreklilik en son gelir, çünkü ancak bir sertifika/karar varsa onun üzerine bir "değişiklik" kavramından söz edilebilir; henüz sertifikalanmamış bir ürün için "delta değerlendirme" anlamsızdır — değişecek bir temel çizgi (baseline) yoktur.

3. Zafiyet değerlendirmesinin yöntemleri¶

Değerlendirme sürecinin 5. ve 6. adımları (kod incelemesi ve zafiyet analizi), bir dizi yöntemi doğru sırada kullanmayı gerektirir. Bunları savunmacı gözüyle, "kendi ürünümü teslim etmeden önce nasıl sınarım?" sorusuyla ele alıyoruz. Sıralama önemlidir: ucuz ve geniş kapsamlı yöntemlerle başlanır, pahalı ve derin yöntemlere doğru gidilir.

Kod incelemesi: değerlendiricinin baktığı yerler¶

Kod incelemesi, otomatik araçların kaçırdığı mantık hatalarını bulur. Değerlendiricinin öncelikli baktığı yerler (hepsi önceki haftalardan):

• Kripto kullanımı: doğru algoritma/kip/dolgu mu? Anahtar nereden geliyor, nereye yazılıyor, ne zaman siliniyor? (3, 10, 11. haftalar)
• Girdi doğrulama ve bellek: sınır denetimi, tamsayı taşması, biçim dizisi, UAF (4. hafta CERT).
• Hata ve sır sızıntısı: günlükte hassas veri, hata iletilerinde iç durum (4, 6. haftalar).
• Denetim atlama yolları: bir güvenlik denetiminin tek bir dalla ya da tek bir dönüş değeriyle atlanabilmesi (Hafta 9, §6 opak boolean, §5 rastgele çıkış).

Her madde neden bu listede? Çünkü hepsi otomatik araçların gözden kaçırdığı hatalardır: bir SAST aracı "burada AES_encrypt çağrılıyor" diyebilir ama "doğru kip kullanılmış mı" (bölüm 3'ün haftası olan 3. haftadaki AES-GCM/CBC/CTR ayrımı) sorusuna genellikle cevap veremez — bu, bağlamı anlayan bir insanın işidir.

Statik ve dinamik analiz, fuzzing¶

Bu üç yöntemi 4. haftada güvenli derleme hattının parçası olarak gördük. Değerlendirmede aynı araçlar, bu kez bağımsız bir tarafça çalıştırılır. Önemli olan, geliştiricinin bu araçları kendisinin çalıştırmış ve sonuçlarını (S16) sunmuş olmasıdır: değerlendirici, "bu ürünü daha önce kimse sınamamış" ile "geliştirici şu araçları çalıştırmış, şu bulguları kapatmış" arasında büyük fark görür.

Bir bellek hatasını beş yöntemle izlemek¶

Bölüm 0'da bir mantık hatasını (SQL enjeksiyonu) beş yöntemle karşılaştırmıştık; şimdi tersini yapıp bir bellek hatasını izleyelim — çünkü yöntemlerin güçlü olduğu alanlar farklıdır.

void tampon_kopyala(char *hedef, const char *kaynak)
{
    strcpy(hedef, kaynak);   /* HATA: hedefin boyutu kontrol edilmiyor */
}

void isle(const char *disaridan_gelen)
{
    char arabellek[64];
    tampon_kopyala(arabellek, disaridan_gelen);   /* disaridan_gelen 64 bayttan uzunsa tasma */
}

Karşılaştırma: SQLi gibi mantık hataları kod incelemesi ve SAST'ta güçlüdür, fuzzing'de zayıftır; bellek hataları ise fuzzing ve sanitizer'larda çok güçlüdür. Bu yüzden bölüm 3'ün sırası (kod inceleme → SAST → DAST/sanitizer → fuzzing → sızma testi) her hata sınıfını en az bir yöntemin güçlü olduğu bir noktadan geçirir.

Yanlış pozitif ve yanlış negatif: otomatik araçların iki riski¶

Bölüm başındaki "SAST hızlı ama yanlış pozitif üretir" cümlesini açalım — bu iki terim değerlendirmede sürekli geçer:

• Yanlış pozitif (false positive): aracın "burada sorun var" dediği ama aslında sorun olmayan durum. Örnek: SAST, strcpy çağrısını görür görmez işaretler; ama hedef tampon zaten güvenli biçimde büyük ayrılmışsa bu bir yanlış pozitiftir. Çok sayıda yanlış pozitif, geliştiricinin aracı kapatmasına (alarm yorgunluğu) yol açar.
• Yanlış negatif (false negative): aracın kaçırdığı gerçek sorun. Örnek: bir SAST aracı yalnız bilinen tehlikeli fonksiyon listesine bakıyorsa, aynı hatayı yapan ama listede olmayan özel bir sarmalayıcı (wrapper) fonksiyonu kaçırır. Yanlış negatif, yanlış pozitiften daha tehlikelidir: "araç temiz dedi" güveni sahte olur.

Neden "ucuzdan pahalıya" sıra bir maliyet meselesidir¶

Bölüm başındaki sıralamayı (kod inceleme → SAST → DAST/sanitizer → fuzzing → sızma testi) bir de göreli maliyet açısından okuyalım. Aşağıdaki tablo gerçek bir ölçüm değil, yalnız fikri somutlaştırmak için verilen gösterim amaçlı bir sıralamadır:

Yöntemler birbirini nasıl doğrular? Çapraz kontrol¶

Bir yöntemin bulduğu bir şeyi başka bir yöntemle doğrulamak, değerlendirmede güveni artırır. Örnek: SAST bir tamsayı taşması adayı işaretler (yanlış pozitif olabilir); DAST/sanitizer aynı yolu gerçek bir girdiyle çalıştırıp taşmanın gerçekten oluştuğunu gösterirse, bu artık bir yanlış pozitif değil, doğrulanmış bir bulgudur. Sızma testi, genellikle bu doğrulanmış bulguları birleştirerek (chaining) gerçek bir saldırı senaryosu kurar — tek başına düşük etkili görünen iki bulgu, birlikte kullanıldığında ciddi bir zincir oluşturabilir.

4. Standartların istediği testler¶

Farklı standartlar farklı test türlerini vurgular. Projenizin hangi gereksinim ailesine yakın olduğunu bilmek, hangi testleri önceliklendireceğinizi belirler.

Her standardın somut bir test örneği¶

Tablodaki "ağırlıklı beklediği test" satırını somutlaştıralım — her standart için bir örnek test sorusu:

• ISO/IEC 27001: "Kart verisine erişimi olan çalışanların listesi güncel mi, erişim üç ayda bir gözden geçiriliyor mu?" — bu bir kod sorusu değil, bir süreç sorusudur; kanıt bir erişim kayıt defteridir, bir test kartı değil.
• Ortak Kriterler: "Anahtar türetme fonksiyonunun tersine mühendislikle kaç saatte kırıldığı, hangi uzmanlık düzeyinde?" — doğrudan bölüm 5'teki saldırı potansiyeli sorusudur.
• FIPS 140-3: "Modül açılışta kendi kendini test ediyor mu (power-up self-test), kriptografik algoritma onaylı bir uygulamayla mı çalışıyor?" — algoritma doğrulama sorusudur, saldırı senaryosu değil.
• ETSI EN 303 645: "Cihazda varsayılan/tahmin edilebilir bir parola var mı?" — temel, geniş kapsamlı bir kontrol sorusudur; derinlemesine sızma testi beklemez.
• EMVCo / PCI: "Kart verisi bellekte ne kadar süre açık kalıyor, işlem bitince siliniyor mu?" — hem kod incelemesi hem laboratuvar sızma testi gerektirir.
• OWASP MASVS: "Uygulama, kök/jailbreak yapılmış bir cihazda çalışırken hassas veriyi koruyor mu?" — hem statik hem dinamik test ister.

GüvenPay'in altı sorusu tek tek yanıtlansa nasıl görünür?¶

Yukarıdaki altı örnek soruyu GüvenPay'e uygulayıp, aynı ürünün **farklı mercekler**den nasıl göründüğünü görelim — bu, "aynı ürün dört farklı sınavdan geçebilir" fikrinin (bölüm 1) somutlaşmış hâlidir:

Ödeme alanında iki ayrı kapsam: yazılım mı, kurum mu?¶

Ödeme güvenliği alanında "PCI" tek bir standart değil, bir standartlar ailesidir; hangisinin geçerli olduğu "neyin" değerlendirildiğine bağlıdır:

• PCI DSS (Data Security Standard): kart verisi işleyen bir kurumun/ortamın uyumunu denetler — sunucular, ağ segmentasyonu, erişim kayıtları. Bir yazılımın kendisi değil, o yazılımın çalıştığı ortam kapsamdadır. ISO/IEC 27001'e benzer şekilde (bölüm 1) süreç ve ortam odaklıdır.
• PCI yazılım standartları (ör. SSF — Software Security Framework, MPoC — Mobile Payments on COTS): bir yazılımın kendisinin (kart verisini nasıl işlediği, sakladığı, sildiği) güvenli tasarlanıp tasarlanmadığını değerlendirir — bu, GüvenPay gibi bir SDK'nın kapsamına daha yakındır.
• EMVCo: çip ve yazılım tabanlı ödeme akışlarının (işlem doğrulama, kriptografik protokol adımları) uygun şekilde uygulanıp uygulanmadığını, laboratuvar sızma testiyle değerlendirir.

Test derinliği her standartta aynı değildir¶

Aynı "sızma testi" sözcüğü, standarttan standarda çok farklı derinlikte bir çalışmayı ifade edebilir:

Aynı gereksinim, altı farklı sözle: bir karşılaştırma¶

"Kart verisi şifrelenmelidir" gibi tek bir güvenlik gereksinimi, farklı standartlarda farklı sözcüklerle, ama aynı temel fikirle karşımıza çıkar. Bu benzerliği görmek, 13. haftadaki uyum matrisini doldururken çok işinize yarayacak:

Standartları kim yazıyor, kim güncelliyor?¶

Zayıf bir öğrencinin sık sorduğu, ama nadiren yanıtlanan bir soru: "bu standartları kim uyduruyor?" Kısa cevap: hiçbiri tek bir kişinin ya da şirketin ürünü değildir; her biri, o alandaki birçok kurumun ortak çalışmasıyla oluşturulur ve düzenli olarak (genelde birkaç yılda bir) güncellenir — tıpkı 2. haftada gördüğümüz CVSS'in v2'den v3.1'e, v4.0'a evrilmesi gibi. Bu güncellemelerin nedeni genelde ya (a) yeni bir saldırı tekniğinin ortaya çıkması ya da (b) önceki sürümün belirsiz/tutarsız bulunan bir maddesinin netleştirilmesidir.

5. Saldırı potansiyeli ve bulgu derecelendirme¶

Bir korumanın "var olması" yetmediğini, "ne kadar kolay aşıldığının" ölçülmesi gerektiğini söylemiştik. Ortak Kriterler ve ödeme şemaları bu ölçüyü saldırı potansiyeli (attack potential) puanlamasıyla yapar. Bir bulgunun ciddiyeti, "kırmak için ne gerekti?" sorusuna verilen yanıtla belirlenir. Bu, Hafta 9, §9'daki "gizlemenin ölçülmesi" (güç, dayanıklılık) çerçevesinin değerlendirmedeki resmî halidir.

Saldırı potansiyeli faktörleri¶

Bir saldırıyı gerçekleştirmek için gereken çabayı beş–altı faktörle puanlarız; her faktörün puanları toplanır ve toplam bir dirençlik düzeyine (ör. "temel / orta / yüksek / çok yüksek") eşlenir.

Yorum: Toplam puan yüksekse, saldırı zor demektir; koruma iyidir. Puan düşükse (ör. sıradan kullanıcı, bir saatte, ücretsiz araçla), bu ciddi bir bulgudur. Buradaki mantık Hafta 9, §9'daki dört ölçütle aynıdır: bir savunmanın gücü, onu aşmanın maliyetiyle ölçülür.

Her faktör neden orada? Tek tek gerekçesi¶

Beş faktör rastgele seçilmemiştir; her biri gerçek bir saldırganın karşılaştığı farklı bir maliyet türünü temsil eder. Zayıf bir öğrencinin en çok karıştırdığı nokta budur — "bunlar neden bu beşi, başka değil?" sorusunun cevabı:

• Geçen süre: saldırganın zamanı sonsuz değildir; bir kurumsal saldırgan bile bir açığı bulmak için ayları değil genelde günleri göze alır. Süre arttıkça, gerçek dünyada bu saldırıyı deneyecek kişi sayısı azalır.
• Uzmanlık: herkes tersine mühendislik ya da kriptanaliz yapamaz. Uzmanlık düzeyi arttıkça, o saldırıyı gerçekleştirebilecek insan havuzu daralır — "sıradan kullanıcı" milyonlarca kişiyi kapsarken "çoklu uzman" belki birkaç yüz kişiyi kapsar.
• Hedef bilgisi: kamuya açık bir bilgiyle (ör. genel API belgesi) yapılabilen bir saldırı, iç/gizli belge gerektiren bir saldırıdan çok daha erişilebilirdir — çünkü saldırganın önce o bilgiyi sızdırması ya da çalması gerekmez.
• Fırsat (erişim penceresi): bir saldırı sınırsız deneme hakkıyla (ör. kendi cihazında, offline) mı yapılıyor, yoksa kısıtlı bir pencerede (ör. bir ATM'ye üç dakikalığına erişim) mi? Deneme sayısı sınırlıysa, saldırganın ilk seferde başarılı olması gerekir — bu çok daha zordur.
• Ekipman: standart, ücretsiz bir araçla (ör. bir hata ayıklayıcı) yapılabilen bir saldırı; özel-uyarlanmış, pahalı bir laboratuvar ekipmanı (ör. odaklı iyon ışını) gerektiren bir saldırıdan erişilebilirlik açısından bambaşka bir kategoridedir.

Puan tablosu (derste kullanacağımız sadeleştirilmiş ölçek)¶

Yukarıdaki tablo "düşük/yüksek" diyor; puanlama yapabilmek için sayılar gerekir. Derste (ve demoda) şu sadeleştirilmiş Ortak Kriterler/JIL ölçeğini kullanıyoruz:

Toplam puanın karşılığı:

Uçtan uca örnek: bir bulguyu baştan sona puanlayalım¶

Senaryo. "Sürüm derlemesindeki lisans denetimi, ücretsiz bir tersine derleyiciyle, yetkin (uzman değil) bir kullanıcının bir saatte bulup tek bayt yamasıyla atlayabildiği bir dala bağlı."

Beş faktörü tek tek okuyup puanlıyoruz:

Toplam = 0 + 3 + 0 + 0 + 0 = 3        →  3 ≤ 9  →  TEMEL

Sonuç: TEMEL düzey = düşük direnç = ciddi bulgu. Rapora "önce bu kapatılmalı" diye yazılır.

Şimdi koruma ekleyelim ve yeniden puanlayalım. 9. haftadan opak boolean + rastgele çıkış, üstüne sunucu tarafı denetim koyduk. Aynı saldırı artık: bir haftada (4), uzman gerektiriyor (6), iç davranışı öğrenmek kısıtlı bilgi istiyor (3), sunucu denetimi yüzünden deneme kısıtlı (4), ekipman hâlâ ücretsiz (0):

Toplam = 4 + 6 + 3 + 4 + 0 = 17       →  14 ≤ 17 ≤ 19  →  YÜKSEK

Yani koruma, bulguyu TEMEL (3) düzeyinden YÜKSEK (17) düzeyine taşıdı. "Koruma ekledim" demek yerine ölçüyle konuşmuş olduk; S16'ya yazılacak cümle budur.

./bin/linux/saldiri_potansiyeli 0 1 0 0 0     # korumasız hâl  -> puan 3  (TEMEL)
./bin/linux/saldiri_potansiyeli 1 2 1 1 0     # korumalı hâl   -> puan 17 (YÜKSEK)

İkinci uçtan uca örnek: tam tersi uçta bir senaryo ("güvenli öğe kırma")¶

İlk örnekte (lisans denetimi) saldırı çok kolaydı. Şimdi ölçeğin öbür ucuna, demodaki üçüncü gömülü örneğe ("Güvenli öğe (SE) kırma") bakalım — bu kez bir saldırının ne kadar zor olabileceğini görmek için.

Senaryo B. "Bir ödeme kartındaki güvenli öğeden (secure element) simetrik ana anahtarın, donanım seviyesinde bir yan kanal/hata enjeksiyonu saldırısıyla çıkarılması. Saldırgan, çip üreticisinin iç belgelerine ve özel olarak uyarlanmış laboratuvar ekipmanına (ör. hassas ölçüm probu, odaklı iyon ışını) erişen, birden fazla alanda (donanım + kriptanaliz) uzman bir ekip gerektiriyor; saldırı aylar sürüyor ve cihaza çok kısıtlı fiziksel erişim istiyor."

Beş faktörü aynı sadeleştirilmiş ölçekle (yukarıdaki puan tablosu) tek tek puanlayalım:

Toplam = 19 + 8 + 11 + 10 + 7 = 55        →  55 >= 25  →  OTESI (yalniz cok yetenekli saldirgan)

Sonuç: ÖTESİ düzey = çok yüksek direnç = düşük öncelikli bulgu (yine de sıfır risk demek değildir — çok kaynaklı bir saldırganın erişimi olabilir; rapor bunu "kalan risk" olarak yazar, bölüm 6 ve 12'de göreceğiz).

Üç sonucun karşılaştırması:

Ek alıştırma: demodaki üçüncü gömülü örneği elle doğrulayalım¶

İki uç örneği (3 ve 55) gördük; demonun ikinci gömülü bulgusunu ("WBC anahtar çıkarma") da elle hesaplayıp aracın çıktısıyla karşılaştıralım:

"Beyaz kutu kriptografi (white-box crypto) uygulamasından anahtar çıkarma; saldırgan çoklu uzman düzeyinde bilgi gerektiren farklı analiz (DCA — differential computation analysis) tekniğini uyguluyor, ürünün iç yapısı hakkında hassas (genel kullanıcıya kapalı) belgeye ihtiyaç duyuyor, saldırı bir ay kadar sürüyor, cihaza erişimi kısıtlı ve özel (hazır satılan bir analiz aracı) kullanıyor."

Toplam = 10 + 8 + 7 + 4 + 4 = 33        ->  33 >= 25  ->  OTESI

Demoda ./bin/linux/saldiri_potansiyeli 2 3 2 1 1 komutuyla (sıra: süre uzmanlık bilgi fırsat ekipman) aynı sonucu (puan=33 -> OTESI) doğrulayabilirsiniz — kod içindeki gömülü "WBC anahtar cikarma (DCA)" örneğiyle birebir aynı girdilerdir. Bu, ilk bakışta "lisans yamasından çok daha zor ama SE kırma kadar da uç olmayan" bir senaryonun bile, beş faktör birlikte toplandığında hızla ÖTESİ bandına çıkabileceğini gösterir; sayılar sezgisel "orta zorlukta" hissinden daha yüksek çıkabilir — bu yüzden tahmin değil, hesap gerekir.

CVSS ile derecelendirme¶

Saldırı potansiyeli "kırmak ne kadar zor?" derken, CVSS (Common Vulnerability Scoring System) "bu zafiyetin etkisi ne kadar büyük?" sorusuna standart bir puan verir. İki ölçü birbirini tamamlar: biri olabilirliği (saldırının zorluğu), öteki etkiyi (gizlilik/bütünlük/erişilebilirlik kaybı) tartar. Bir bulgu raporunda çoğunlukla ikisi birden verilir; önceliklendirme buna göre yapılır.

Aynı bulgu, iki farklı puan: CVSS neden saldırı potansiyelinden farklı çıkar?¶

Şimdi aynı bulguyu (Senaryo B — güvenli öğeden anahtar çıkarma) hem saldırı potansiyeliyle (yukarıda: 55, ÖTESİ) hem de CVSS ile puanlayalım; ikisinin neden aynı sayıyı vermediğini adım adım görelim.

CVSS v3.1 taban puanı, sekiz metrikten hesaplanır (Hafta 2, §15'te tanıtıldı); burada ilgili dördünü kullanıyoruz:

• Saldırı vektörü (AV): saldırgan nereden erişiyor? Ağ (N) · Bitişik (A) · Yerel (L) · Fiziksel (P). Senaryo B fiziksel erişim istiyor → AV:P.
• Saldırı karmaşıklığı (AC): koşullar saldırganın kontrolü dışında mı zorlaşıyor? Düşük (L) · Yüksek (H). Özel ekipman + uzman ekip gerektiren bir donanım saldırısı → AC:H.
• Gerekli yetki (PR) / kullanıcı etkileşimi (UI): saldırgan önceden bir hesaba ya da kullanıcı eylemine mi ihtiyaç duyuyor? Burada hiçbiri gerekmiyor → PR:N, UI:N.
• Etki (C/I/A): başarılı olursa sonuç ne kadar kötü? Ana anahtar ele geçerse bütün kartların gizliliği, bütünlüğü ve işlem onayının güvenilirliği çöker → C:H, I:H, A:H (tam kayıp).

Vektör: AV:P/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

CVSS v3.1 formülü iki alt puanı birleştirir: Etki (impact) alt puanı yalnız C/I/A'dan, Sömürülebilirlik (exploitability) alt puanı AV/AC/PR/UI'den hesaplanır. Sayıları kendimiz toplayalım:

Etki alt puani (Scope: Degismedi, C=H, I=H, A=H -> her biri 0.56):
  ISS    = 1 - [(1-0.56) x (1-0.56) x (1-0.56)]
         = 1 - (0.44 x 0.44 x 0.44)
         = 1 - 0.085184
         = 0.914816
  Impact = 6.42 x ISS = 6.42 x 0.914816 = 5.873   (ara deger)

Somurulebilirlik alt puani (AV:P=0.20, AC:H=0.44, PR:N=0.85, UI:N=0.85):
  Exploitability = 8.22 x 0.20 x 0.44 x 0.85 x 0.85 = 0.523   (ara deger)

Taban puan = yukari_yuvarla( min(5.873 + 0.523, 10) )
           = yukari_yuvarla(6.396)
           = 6.4   ->  "Orta" bandi (NVD: 4.0-6.9)

Şimdi aynı etkiyi (C:H/I:H/A:H) ama farklı bir erişim biçimiyle karşılaştıralım — bu yalnız öğretim amaçlı bir karşılaştırma, GüvenPay ürününde böyle bir açık iddia edilmiyor. Aynı sonucu ağ üzerinden, düşük karmaşıklıkla elde edebilen varsayımsal bir açık olsaydı (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H):

Exploitability = 8.22 x 0.85 x 0.77 x 0.85 x 0.85 = 3.887
Taban puan     = yukari_yuvarla( min(5.873 + 3.887, 10) ) = yukari_yuvarla(9.760) = 9.8  -> "Kritik"

Neden farklı çıkıyor? Çünkü iki ölçü farklı soruları farklı çözünürlüklerle yanıtlıyor:

• CVSS'in AV/AC metrikleri kaba, kategorik seçeneklerdir (N/A/L/P; L/H) — "fiziksel erişim ve yüksek karmaşıklık" demek, saldırının bir hafta mı yoksa altı ay mı süreceğini, bir kişi mi yoksa beş uzmanlık dalından bir ekip mi gerektiğini ayırt etmez.
• Saldırı potansiyeli ise süreyi, uzmanlığı, bilgiyi, fırsatı ve ekipmanı ayrı ayrı, ince taneli puanlar (0'dan 19'a kadar) toplar — tam olarak "altı ay + beş uzman + özel iyon ışını" ile "bir gün + tek kullanıcı + ücretsiz araç" arasındaki farkı yakalamak için tasarlanmıştır.
• CVSS etkiyi (bu açık gerçekleşirse ne olur) ölçer; saldırı potansiyeli maliyeti (bu açığı gerçekleştirmek ne kadara mal olur) ölçer. İkisi de "yüksek" çıkabilir (Senaryo B'de olduğu gibi: etki felaket ama maliyet çok yüksek), ya da ikisi de "düşük" çıkabilir (lisans yaması örneğinde olduğu gibi).

Zincirleme saldırılar: birden fazla zafiyetin birleşimi¶

Bölüm 2'nin sonunda "iyi tasarlanmış bir üründe saldırgan birkaç korumayı zincirlemek zorunda kalır" demiştik; bunu saldırı potansiyeli diliyle açalım. Tek başına çok yüksek dirençli (ör. ÖTESİ) bir koruma bile, başka bir zafiyetle birleşince toplam direnç düşebilir. Örnek: Senaryo B'deki güvenli öğe (ÖTESİ, puan 55) tek başına neredeyse sömürülemez; ama eğer ayrıca cihazın işletim sistemi eski bir sürümdeyse ve bilinen bir kök (root) açığı varsa, saldırgan önce o daha kolay açıkla cihaza tam erişim kazanıp, sonra donanım saldırısı için gereken "çok kısıtlı" fırsatı "sınırsız"a çevirebilir — bu da fırsat faktörünü 10'dan 0'a düşürür ve toplam puanı 55'ten 45'e indirir (hâlâ ÖTESİ, ama daha kolay bir ÖTESİ).

6. Bulgu → öneri → aksiyon ve etki analizi¶

Değerlendirme bir "geçti/kaldı" damgası değil, bir iyileştirme döngüsüdür. Her bulgu için:

1. Bulgu: laboratuvar ne buldu (kanıtla, tekrarlanabilir biçimde).
2. Öneri: laboratuvarın önerdiği düzeltme yönü.
3. Aksiyon: geliştiricinin ne yaptığı (ya da neden yapmadığı — gerekçeli kabul de bir aksiyondur).
4. Kapanış: bazı bulgular "güvenlik açığı değil, iyi uygulama önerisi" olarak da kapanabilir.

Bu döngü, vize sonrası projenizde beklediğimiz bulgu–aksiyon listesinin (7. hafta) kaynağıdır.

Güvenlik etki analizi ve delta değerlendirme¶

Düzeltmeler yeni bir sürüm doğurduğunda, her şeyi baştan değerlendirmek pahalıdır. Bu yüzden iki belge devreye girer (süreçteki 10. ve 11. adımlar):

• Güvenlik etki analizi (security impact analysis): Yeni sürümdeki değişiklikleri sınıflandırır (yeni özellik / iyileştirme / hata düzeltmesi), etkilenen dosyaları listeler ve her değişikliğin güvenlik etkisini yazar.
• Delta değerlendirme: Laboratuvar, bu belgeye dayanarak yalnız değişen kısmı yeniden değerlendirir; işaretli belgeleri, değişiklik dizinini, dosya listesini ve yeni TOE kimliğini ister.

Uçtan uca örnek: bir bulgunun doğuşundan kapanışına¶

Bölüm 2'deki GüvenPay örneğinde geçen "F-03: sabit tuzla anahtar türetme" bulgusunu, dört adımın her birinde somut olarak izleyelim — bu, projenizin bulgu–aksiyon tablosunun nasıl doldurulacağının tam örneğidir.

1. Bulgu (laboratuvar, 12 Kasım): "anahtar_yonetimi.c satır 22'de anahtar türetme fonksiyonu sabit bir dize (\"guvenpay_tuz_2024\") kullanıyor. Kanıt: iki farklı test cihazında aynı girdiyle çalıştırıldığında aynı 64 baytlık anahtar üretildi (ekran çıktısı ekte). Saldırı potansiyeli: süre < 1 gün (kaynak kodda görülüyor), uzmanlık sıradan, bilgi kamuya açık, fırsat sınırsız, ekipman ücretsiz → toplam 0, TEMEL (bölüm 5'teki puan tablosuyla)."
2. Öneri (laboratuvar, aynı raporda): "Her cihaz için benzersiz, CSPRNG'den (hafta 3) üretilmiş bir tuz kullanın; tuzu cihaza özgü güvenli depoda saklayın; HKDF ile anahtar türetin."
3. Aksiyon (GüvenPay, 15 Kasım): "Kabul edildi. anahtar_yonetimi.c içinde işletim sisteminin CSPRNG'i (hafta 3) ile 32 baytlık rastgele tuz üretiliyor, cihazın güvenli deposuna yazılıyor. Değişiklik v3.2.1'e girdi."
4. Kapanış (laboratuvar, delta değerlendirme sonrası, 22 Kasım): "Doğrulandı: iki cihazdan artık farklı anahtar üretiliyor. Bulgu kapandı."

Karşılaştırma için, "güvenlik açığı değil, iyi uygulama önerisi" olarak kapanan bir örnek de görelim: "Bulgu F-07: günlük mesajları yalnız İngilizce, Türkçe hata mesajı yok." GüvenPay yanıtı: "Bu bir güvenlik açığı değil, günlük mesajları hiçbir hassas veri içermiyor (kanıt: F-03 incelemesinde günlük çıktısı da kontrol edildi) — kullanılabilirlik önerisi olarak not edildi, güvenlik bulgusu listesinden çıkarıldı." Laboratuvar bu gerekçeyi kabul eder ve bulguyu "etkilenmez" olarak kapatır.

Uçtan uca örnek: bir güvenlik etki analizi belgesi¶

Adım 10'daki etki analizini tam olarak GüvenPay'in v3.2.0 → v3.2.1 geçişi için yazalım (bu, projenizde vize sonrası bir düzeltme yaptığınızda dolduracağınız belgenin küçültülmüş hâlidir):

Kalan risk: her şey kapanmaz, kapanmayan açıkça yazılır¶

Bölüm 0'da tanımladığımız kalan risk kavramını burada somutlaştıralım. GüvenPay'in F-08 bulgusunu (anahtar rotasyonu yılda bir kez) düşünelim: laboratuvar bunun daha sık yapılmasını önerir, ama GüvenPay performans ve kullanıcı deneyimi maliyetini gerekçe göstererek riski kabul eder. Rapor bunu şöyle yazar: "F-08: anahtar rotasyon sıklığı yılda bir. Saldırı potansiyeli: YÜKSEK (17) — kolay değil ama imkânsız da değil. GüvenPay bu riski, performans maliyeti gerekçesiyle kabul etmiştir; kalan risk laboratuvar tarafından kayıt altına alınmıştır, kapatılmamıştır."

F-03'ün tüm yaşam döngüsü: bir zaman çizelgesinde¶

Bu haftanın birçok bölümünde F-03 bulgusunu farklı açılardan gördük — bölüm 2'de nasıl bulunduğunu, bu bölümde bulgu-aksiyon döngüsünü, bölüm 7'de test kartlarını (PT-03/PT-07). Hepsini tek bir zaman çizelgesinde toplayalım; bu, bir bulgunun baştan sona nasıl izlendiğinin tam resmidir:

Delta değerlendirmede kapsam kayması (scope creep)¶

Bir düzeltme yaparken sık karşılaşılan bir tuzak: geliştirici "zaten oradaydım" diyerek F-03'ü düzeltirken ilgisiz başka küçük değişiklikler de yapar (ör. bir arayüz metnini günceller, kullanılmayan bir fonksiyonu siler). Etki analizi belgesi yalnız F-03'ü anlatırsa, laboratuvar delta değerlendirmede beklenmedik bir dosya değişikliği görür.

Ne zaman bir düzeltme yeni bir zafiyet getirir?¶

Bölüm 10'daki (adım) etki analizi belgesi hep "iyileştirdi" örnekleriyle anlatılır; ama gerçekte bir düzeltme yeni bir sorun da getirebilir. Kurgusal bir örnek: GüvenPay, F-03'ü kapatırken tuzu güvenli depoya yazarken bir hata ayıklama derlemesinde yanlışlıkla tuzu da günlüğe yazdıran bir satır bırakır. Delta değerlendirme sırasında laboratuvar yalnız "tuz artık benzersiz mi?" sorusuna değil, anahtar_yonetimi.c dosyasının tamamına bakar ve bu yeni günlük satırını fark eder — yeni bir bulgu (F-11) olarak kaydeder.

7. Sızma testi planı¶

Sızma testi, yukarıdaki yöntemleri saldırgan bakışıyla birleştiren, planlı ve izinli bir etkinliktir. "Planlı" ve "izinli" sözcükleri isteğe bağlı değildir: kapsamı ve kuralları yazılı olmayan bir test, meşru bir güvenlik çalışması değildir. Bir plan en az şu dört başlığı içerir.

1. Kapsam (scope)¶

Neyin test edileceği ve neyin edilmeyeceği açıkça yazılır: hangi ikili dosya/sürüm, hangi bileşenler, hangi ortam (test ortamı mı, üretim mi), hangi veriler (yalnız sentetik). Kapsam dışı bırakılanlar da yazılır (ör. üçüncü taraf sunucular, gerçek kullanıcı verisi).

2. Angajman kuralları (rules of engagement)¶

• Yazılı izin ve yetkili imzası; test penceresi (tarih/saat).
• İzin verilen ve yasak yöntemler (ör. hizmet kesintisine yol açacak testler hariç).
• Veri işleme kuralı: gerçek kişisel veri kullanılmaz; bulgular gizli tutulur.
• Durdurma koşulu (kill switch): kritik bir etki görülürse test durur ve derhal bildirilir.
• İletişim ve yükseltme (escalation) noktaları.

3. Yöntem (methodology)¶

Tanınmış bir metodoloji seçilir ve ona uyulur: mobil için OWASP MASTG/MASVS, web için OWASP WSTG, genel süreç için PTES ya da NIST SP 800-115. Yöntem seçimi, sonucun tekrarlanabilir ve karşılaştırılabilir olmasını sağlar.

4. Test şablonu (sekiz başlık)¶

Değerlendirmedeki her test aynı şablonla yazılır; bu, projenizin S16 bölümünün de iskeletidir:

Sekiz alan da rastgele seçilmemiştir; her biri, testin tekrarlanabilir ve tartışılabilir olması için gerekli bir soruyu yanıtlar:

• Test kimliği: bir bulguyu (bölüm 6) ya da rapor satırını (bölüm 8) hangi teste bağlayacağınızı bilmeniz gerekir — kimliksiz bir test, kanıtı olmayan bir iddiadır.
• İlgili gereksinim: bir test, hiçbir gereksinime bağlı değilse "neden bu testi yapıyoruz?" sorusuna cevap veremez; bu alan S17 uyum matrisine giden köprüdür.
• Amaç: "ne doğrulanıyor" cümlesi olmadan, bir okuyucu testin neyi kanıtlamaya çalıştığını anlayamaz.
• Ön koşullar: hangi sürüm, hangi ortam, hangi veriyle test edildiği yazılmazsa, aynı testi bir başkası tekrar edemez (delta değerlendirmede bu hayati önemdedir).
• Yöntem/adımlar: adım adım yazılmamış bir test, "nasıl yaptım hatırlamıyorum" riskini taşır; tekrarlanabilirlik burada da kilit kelimedir.
• Beklenen sonuç: önceden yazılmazsa, testi çalıştıran kişi sonucu istediği gibi yorumlama eğilimine girebilir (bilişsel önyargı, bölüm 1'deki "geliştirici kendi ürününü onaylayamaz" mantığının küçük ölçekli hâli).
• Gözlenen sonuç: kanıtsız bir "çalıştı" cümlesi, bölüm 0'da tanımladığımız anlamda bir bulgu bile değildir.
• Saldırı potansiyeli/karar: testin sonucunu bir önceliğe (bölüm 8'deki öncelik matrisi) çevirir.

Doldurulmuş bir test kartı örneği¶

Aşağıda, sekiz başlıklı şablonun gerçekten doldurulmuş hâlini görüyoruz — Hafta 3, §2'deki AES-GCM/AEAD demosuyla doğrudan bağlantılı bir test:

Bir de KALDI (başarısız) örneği görelim¶

PT-07 geçti; ama bir test kartının kaldığı durumu da görmeden bölüm eksik kalır — çünkü bir öğrencinin en sık yaptığı hata, yalnız geçen testleri göstermektir. Aynı GüvenPay'in ilk sürümünde (v3.2.0, F-03 düzeltilmeden önce) aynı test şöyle sonuçlanırdı:

8. Raporlama¶

İyi bir güvenlik raporu, bir "kaldınız" listesi değil, karar verilebilir bir belgedir:

• Yönetici özeti: teknik olmayan okur için genel durum ve en kritik üç bulgu. Okuyucu genellikle bir yönetici ya da müşteridir; "kaç bulgu var" değil, "üretime hazır mıyız" sorusuna doğrudan cevap verir.
• Yöntem ve kapsam: ne test edildi, ne edilmedi, hangi metodolojiyle. Kapsam dışı bırakılanların neden dışarıda kaldığı da yazılır — aksi hâlde okuyucu "test edilmedi mi, yoksa unutuldu mu" ayrımını yapamaz.
• Bulgular: her biri kanıt, saldırı potansiyeli ve CVSS, öneri ile. Bulgular önem sırasına göre (en ciddi önce) listelenir; her biri tek başına okunduğunda bile anlaşılır olmalıdır.
• Bulgu–aksiyon tablosu: geliştiricinin yanıtı ve kapanış durumu. Bu, bölüm 6'daki dört adımlı döngünün (bulgu → öneri → aksiyon → kapanış) rapordaki karşılığıdır.
• Kalan risk: kapatılmayan ya da devredilen riskler, gerekçesiyle. Bu bölüm atlanamaz: bir raporun en çok güven kazandıran kısmı, aslında "her şeyi çözdük" değil, "şunu çözemedik, işte nedeni" cümlesidir.

Bir rapor, birden çok okuyucuya hizmet eder¶

Yukarıdaki beş bölümün neden hepsinin gerekli olduğunu anlamak için, aynı raporu kim okuyacak sorusunu soralım — her bölüm aslında farklı bir okuyucu için yazılır:

Örnek: bir yönetici özeti paragrafı¶

Örnek: bir bulgu satırının rapor biçimi¶

Bulgular tablosunda her satır aynı disiplinle yazılır — kanıt, saldırı potansiyeli/CVSS, öneri birlikte:

(*Bu örnekteki CVSS değerleri gösterim amaçlıdır; gerçek puanlama bölüm 5'teki AV/AC/PR/UI/C/I/A seçimleriyle ve standart CVSS hesaplayıcısıyla yapılır.)

Bulguları önceliklendirmek: basit bir öncelik matrisi¶

Bölüm 5'te CVSS'in etkiyi, saldırı potansiyelinin maliyeti ölçtüğünü görmüştük. Bir raporda düzinelerce bulgu varsa, hangisine önce bakılacağı bu ikisinin birleşiminden çıkar. Aşağıdaki matris, resmî bir standart değil, bu ders için kullandığımız basit bir öğretim aracıdır — gerçek şemalarda öncelik kuralları daha ayrıntılıdır, ama fikir aynıdır:

GüvenPay örneğine uygulayalım: F-03 (CVSS Orta, saldırı potansiyeli TEMEL) tabloda "yüksek öncelik" hücresine düşer — tam olarak bu yüzden ilk kapatılan bulgu odur. F-08 (CVSS Orta, saldırı potansiyeli YÜKSEK) "orta öncelik" hücresine düşer — kalan risk olarak kabul edilebilir olması bu yüzden makuldür.

Rapor ne kadar uzun olmalı?¶

Zayıf bir öğrencinin sık düştüğü iki uç vardır: ya tek sayfalık, kanıtsız bir "her şey güvenli" raporu yazmak, ya da her ayrıntıyı (her SAST uyarısını, doğrulanmamış her aday bulguyu) art arda dökmek. İkisi de yanlıştır:

• Çok kısa rapor: okuyucu hangi kararın neye dayandığını göremez; "güvenli" kelimesi bir kanıt değildir (bölüm 1'deki "iddia değil kanıt" kuralı).
• Çok uzun, filtrelenmemiş rapor: doğrulanmamış onlarca SAST uyarısını olduğu gibi dökmek, okuyucunun gerçek üç-beş kritik bulguyu gürültü içinde kaybetmesine yol açar (yanlış pozitif tartışmasının, bölüm 3, raporlama düzeyindeki karşılığı).

9. Dönem projesi: bu hafta (S16 — test planı ve sonuçları)¶

1. Test planı: En kritik iki–üç varlık/gereksinim için sekiz başlıklı test kartları yazın (S17 ile bağlı).
2. Yöntem: Hangi metodolojiyi (MASTG/WSTG/PTES/NIST SP 800-115) temel aldığınızı belirtin.
3. Sonuçlar: Testleri çalıştırıp gözlenen sonuçları yazın — finalde plan değil, sonuç beklenir.
4. Bulgu–aksiyon: Vize geri bildirimlerini bir bulgu–aksiyon tablosuna dökün.
5. Kalan risk: Kapatmadığınız riskleri ve gerekçesini yazın.

Bu madde 4 neden özellikle önemli: vize geri bildirimleriniz zaten birer "bulgu"¶

Öğretim üyesinin vize sunumunuzda verdiği her geri bildirim, aslında bu haftanın diliyle bir **bulgu**dur: bir zayıflık, kanıtla (sunumdaki gözlem) işaretlenmiş bir gözlem. Bu haftanın 4 adımlı döngüsünü (bölüm 6) doğrudan kendi projenize uygulayın:

1. Bulgu: öğretim üyesinin vizede söylediği somut cümle (ör. "girdi doğrulaması eksik").
2. Öneri: bu geri bildirimden çıkan somut düzeltme yönü.
3. Aksiyon: finale kadar ne yaptığınız (kod değişikliği, commit referansı).
4. Kapanış: düzeltmeyi kanıtlayan bir test (yeni ya da güncellenmiş bir test kartı).

10. Kendini sınama¶

Bu haftanın terimleri: yan yana karşılaştırma¶

Bu haftanın en sık karıştırılan beş terim çiftini, sınava girmeden önce son bir kez yan yana koyalım:

11. Kaynaklar ve ileri okuma¶

• Güvenli programlama teknik kılavuzu (ders kaynağı) — teslim edilen güvenlik kılavuzunun ve değişiklik/etki analizi belgelerinin yapısı; gereksinim bloğu ve durum ("karşılandı / devredildi / karşılanmadı").
• OWASP MASVS ve MASTG — mobil uygulama güvenlik gereksinimleri ve test rehberi.
• OWASP WSTG — web uygulama güvenlik testi rehberi.
• PTES (Penetration Testing Execution Standard) ve NIST SP 800-115 — sızma testi süreç metodolojileri.
• Ortak Kriterler (ISO/IEC 15408) ve ilgili saldırı potansiyeli kılavuzları — 13. haftaya köprü.
• CVSS — zafiyet ciddiyet puanlaması; taban puan formülünün ayrıntılı hesaplama adımları CVSS v3.1 Belirtimi'nde (FIRST.org) yayımlanır.

Bu haftanın tek paragrafta özeti¶

Bir ürün, bağımsız bir laboratuvarda beyaz kutu erişimle, kod incelemesi → SAST → DAST → fuzzing → sızma testi sırasıyla incelenir; her zafiyet kanıtla bir bulguya, her bulgu saldırı potansiyeli (beş faktör: süre, uzmanlık, bilgi, fırsat, ekipman) ve CVSS (etki) ile bir önceliğe dönüşür; geliştirici düzeltme yapınca laboratuvar yalnız değişeni delta değerlendirmeyle yeniden inceler; kapatılmayan her risk açıkça yazılır; ve tüm bu zincir — bulgu, test kartı, etki analizi, aksiyon — birbirine referans vererek izlenebilir kalır. GüvenPay örneğinde baştan sona izlediğimiz F-03 zinciri (Adım 5 → PT-03 → bulgu → düzeltme → PT-07 → kapanış), bu paragrafın tek bir gerçek zamanlı örneğidir.