Hafta 13 — Güvenlik Gereksinimleri¶

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-13\01-uyum-matrisi
.\bin\windows\uyum.exe
cd ..\02-gereksinim-kalite
.\bin\windows\gereksinim_kalite.exe

# WSL / Linux
./build.sh
cd week-13/01-uyum-matrisi && ./bin/linux/uyum
cd ../02-gereksinim-kalite && ./bin/linux/gereksinim_kalite

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¶

• Varlık, tehdit ve uygulama koruma planı — bir yazılımın güvenliğini yöneten yazılı plan: kapsam, mimari ve arayüzler, varlıklar, tehditler, karşı önlemler, doğrulama, kalan risk; her varlık için nerede durduğu, ne zaman oluşup silindiği ve hangi korumayı (C/I) gerektirdiği bir varlık tablosunda listelenir (Hafta 1, §6). Bu hafta §2'de her gereksinimi bu tabloya ve tehdit modeline bağlıyoruz, §7'de bu bağlamayı bir karar sürecine dönüştürüyoruz.
• Bağımsız değerlendirme, bulgu ve kanıt — bir ürünün geliştiricisi değil bağımsız bir laboratuvarın kanıta dayalı olarak yürüttüğü değerlendirme süreci; değerlendiricinin belgelediği her eksiklik bir bulgudur (Hafta 12, §2). Bu hafta §2'de aynı disiplini "gereksinimden kanıta izlenebilirlik zinciri" olarak, §9'da ise dönem projenizin S17/S14 bölümleri olarak kullanıyoruz.

Bu haftanın kavram haritası¶

Neden bu kadar çok terim var? (gerekçe)¶

Sertifikasyon dünyası kendi kelime dağarcığını kullanır çünkü değerlendirici sizin projenizi değil, belgenizi okur. Belgede "gereksinim" dediğiniz şey aslında bir "önlem"se, değerlendirici ikisini birbirine karıştırıp yanlış soru sorar: "Bu önlemin kanıtı nerede?" yerine "Bu gereksinim neden bir önlem gibi yazılmış, ne karşılıyor?" diye sorması gerekir. Terimler tutarlı kullanılmazsa izlenebilirlik zinciri (2. bölüm) kurulamaz; her kelime başka bir kutuya (gereksinim mi, önlem mi, kanıt mı) karşılık gelir ve bu kutular birbirine karışırsa matris anlamsızlaşır. Bu yüzden bu dersin gerektirdiği disiplin, önce doğru kelimeyi doğru yerde kullanmaktır; teknik çözüm ikinci adımdır.

'Gereksinim ailesi' ile 'standart' farkı¶

Bu derste iki farklı kaynaktan gelen iki farklı şey kullanılır ve bunları karıştırmak yaygın bir hatadır:

• Standart: dışarıdan gelen, dersin yazmadığı bir belge (ör. ETSI EN 303 645, Ortak Kriterler, FIPS 140-3, OWASP MASVS). Kendi madde numaraları ve kendi kurumu vardır.
• Dersin gereksinim ailesi: bu standartlardan uyarlanmış, CEN429-<aile>-<numara> kimlikli, dersin kendi kısa listesi (8. bölüm). Amacı, farklı standartların ortak paydasını tek bir çalışılabilir listede toplamaktır.

Bir gereksinimi yazarken "hangi standarda dayanıyor" (kaynak) ile "dersin hangi ailesine giriyor" (kimlik) iki ayrı sorudur; ikisini de S1 (kaynaklar) ve S17 (uyum matrisi) bölümlerinde ayrı ayrı belirtirsiniz. 6. bölümde bu ikisinin aynı ihtiyacı nasıl farklı sözcüklerle ifade ettiğini dört standart üzerinden göreceğiz.

'Karşılanmadı' ile 'uygulanmaz' farkı¶

Bu iki durum sık karıştırılır ama çok farklı anlamlara gelir; ikisini de doğru kullanmak, matrisin güvenilirliği için gereksinim durumları kadar önemlidir:

• Karşılanmadı: gereksinim ürüne uygulanıyor ama henüz sağlanmıyor. Bu bir eksikliktir, kalan riske yazılır ve bir sonraki sürüm planına girer.
• Uygulanmaz: gereksinim ürüne hiç uygulanmıyor (ör. ürün ağ bağlantısı kullanmıyorsa "aktarımda veri" gereksinimleri uygulanmaz). Bu bir eksiklik değildir, ama gerekçesiz yazılırsa değerlendirici bunu "gereksinim atlanmış, kontrol edilmemiş" sayar.

Bu ayrımın sık yapılan hatasını ve kuralını, gereksinimleri projeye aktarırken 7. bölümde tekrar göreceğiz.

Bu bölümde gördüğümüz altı durum/karar kelimesi¶

Bölüm boyunca gördüğümüz durum ve karar kelimelerini bir arada toplayalım; bunlar dönem projenizde S17 ve S14'ü doldururken tekrar tekrar kullanacağınız kelimelerdir:

Bu tabloyu aklınızda tutmak, ilerideki bölümlerde göreceğiniz bütün örnekleri okurken size bir referans noktası verecektir.

1. Güvenlik gereksinimi nedir? İyi gereksinim nasıl yazılır?¶

Dönem boyunca her önlemi bir tehdide bağladık: "şu varlığı, şu saldırgana karşı koruyoruz." Sertifikasyon dünyasında aynı bağ bir adım daha uzar: her önlem bir gereksinime bağlanır. Gereksinim, ürünün ne yapması gerektiğini söyler; nasıl yapacağını söylemez. Tasarım ve kod "nasıl"ı cevaplar; değerlendirici ise "gereksinim karşılanmış mı, kanıtı nerede?" diye sorar.

Bir gereksinim yazmaya başlamadan önce hangi türden söz ettiğimizi netleştirmek gerekir; gereksinimler üç ana türe ayrılır:

Üç tür gereksinim¶

Kötü ve iyi gereksinim¶

İyi bir gereksinimin özellikleri: tekil (bir cümle, bir gereksinim), doğrulanabilir (bir test ya da inceleme ile karşılandığı gösterilebilir), izlenebilir (bir kimliği vardır ve bir tehdide ya da standarda bağlıdır), uygulanabilir (teknik olarak mümkündür) ve nasıl değil ne (çözümü dayatmaz; ama güvenlik düzeyi gibi ölçütleri verir).

İşlenmiş örnek: kötü bir gereksinimi adım adım iyileştirmek¶

Yukarıdaki tabloda bitmiş hâlleri gördünüz; şimdi süreci görelim. Başlangıç cümlesi gerçek bir kılavuz taslağından alınmış gibi düşünülebilir:

"Uygulama, kullanıcı verilerini korumalıdır."

Adım 1 — Belirsiz kelimeleri işaretleyin. "Kullanıcı verileri" (hangi veri?) ve "korumalıdır" (neye karşı, hangi düzeyde?) ölçülemez. Bir değerlendirici bu cümleyi okuduğunda test edecek hiçbir şey bulamaz; "korunuyor" demek için hangi kanıtı isteyeceğini bilemez. Bu, "iyi vs kötü gereksinim" tablosundaki ilk satırın ("uygulama güvenli olmalıdır") aynı hastalığıdır: cümle her şeyi ve hiçbir şeyi söylüyor.

Ara adım: "Uygulama, kullanıcı verilerini korumalıdır." → hangi veri, hangi tehdide karşı belli değil.

Adım 2 — Varlık tablosuna bağlayın (1. hafta). "Kullanıcı verileri" tek bir şey değildir; varlık tablosunda ayrı ayrı satırlardır: oturum belirteci, profil bilgisi, ödeme jetonu, günlük kayıtları... Her biri farklı bir gizlilik/bütünlük sınıfına (C/I/I+/N) sahiptir ve farklı bir gereksinim gerektirir. Bu adımda tek cümleyi, varlık tablosundaki C sınıfı işaretli olan "yerel veritabanındaki hassas alanlar" ile sınırlıyoruz.

Ara adım: "Yerel veritabanındaki C sınıfı alanlar korunmalıdır." → hâlâ "korunmalı" ölçülemez.

Adım 3 — Koruma hedefini (gizlilik mi, bütünlük mü, ikisi mi) netleştirin. Tehdit modelinde (1. hafta) bu veriye yönelik tehdit "cihazı ele geçiren saldırganın veritabanı dosyasını okuması"dır — yani gizlilik tehdidi. Ama saldırgan dosyayı değiştirip uygulamayı kandırabilir mi diye de sorarız — evet, o zaman bütünlük de gerekir. İki hedefin de aynı anda gerekli olduğunu fark etmek, bir sonraki adımı belirler.

Ara adım: "Yerel veritabanındaki C sınıfı alanların gizliliği ve bütünlüğü korunmalıdır." → "nasıl" hâlâ yok, ölçülebilir bir kriter yok.

Adım 4 — Ölçülebilir bir teknik kriter ekleyin (9. hafta koruma kurallarına bağlanarak). 9. haftada gördüğümüz kural: gizlilik ve bütünlüğü aynı anda istiyorsanız doğru araç sınıfı AEAD'dir (bkz. 3. hafta). Bu, gereksinime somut, teknolojiden bağımsız bir ölçüt katar; hâlâ belirli bir kütüphane adı vermiyoruz.

Ara adım: "Yerel veritabanındaki C sınıfı alanlar kimlik doğrulamalı şifrelemeyle (AEAD) korunmalıdır." → hangi güç, ne zaman doğrulanacak henüz yazılmadı.

Adım 5 — Durumu (beklemede/kullanımda/aktarımda) ve zorunluluk sözcüğünü ekleyin. Veri burada beklemededir (disk üzerinde duruyor, aktarılmıyor). Zorunluluk sözcüğü olarak "-malıdır" (MUST) seçiyoruz çünkü bu, tehdide karşı vazgeçilmez bir koşul; "-abilir" (MAY) olsaydı değerlendirici bunu isteğe bağlı sayardı ve karşılanmasa bile bulgu yazmazdı.

Ara adım: "Beklemedeki C sınıfı hassas veri, kimlik doğrulamalı şifrelemeyle (AEAD) korunmalıdır." → doğrulama yöntemi hâlâ yazılmadı; bu, gereksinim metninin kendisinde değil izlenebilirlik matrisinde (2. bölüm) belirtilir.

Adım 6 — Kimlik verin ve tehdide bağlayın. Son olarak gereksinime dersin aile şemasından bir kimlik veriyoruz (8. bölüm) ve hangi tehdide karşılık geldiğini not ediyoruz; kimliksiz bir gereksinim izlenebilirlik zincirine hiç girmez.

Son hâl: CEN429-DR-01 — "Beklemedeki C sınıfı hassas veri, kimlik doğrulamalı şifrelemeyle (AEAD) korunmalıdır." (Tehdit: T-03 "cihazı ele geçiren saldırgan veritabanı dosyasını okur/değiştirir", 1. hafta tehdit modeli.)

Altı adımın her biri belirsizliğin bir türünü giderdi: hangi veri (varlık tablosu), hangi tehdide karşı (tehdit modeli), hangi hedef (gizlilik/bütünlük), hangi araç sınıfı (AEAD — çözümün kendisi değil, sınıfı), hangi durum (beklemede) ve hangi zorunluluk (MUST). Bu altısından biri eksik kalırsa gereksinim yine tartışmaya açık kalır ve değerlendirici geri gönderir.

İkinci örnek: sürecin hız testi¶

Süreci daha hızlı uygulamak için aynı altı adımı çok daha kısa bir örnekte tekrar görelim; bu kez tablo hâlinde:

Son hâl: CEN429-ID-04 — "Her oturum açma denemesi sunucu tarafında doğrulanmalıdır; istemci tarafı kontrolü tek başına yeterli kabul edilmemelidir."

"Hızlı" kelimesi ayrı bir performans gereksinimi olarak ele alınır (bu ders kapsamı dışında) — bu da tekillik kuralının bir başka yüzüdür: güvenlik ve performans gereksinimlerini aynı cümlede karıştırmak, hangisinin karşılanıp hangisinin karşılanmadığını belirsizleştirir; ikisi ayrı hızda ilerleyebilir.

Zorunluluk sözcüklerini örnekle pekiştirelim¶

Bu üç sözcüğü karıştırmanın somut sonucu: bir SHOULD gereksinimini MUST gibi yazıp karşılayamazsanız, aslında gerekçe yazmanız yeterliyken kendinizi gereksiz yere "karşılanmadı / kalan risk" durumuna sokmuş olursunuz. Tersi de olur: bir MUST'ı SHOULD gibi yumuşatıp karşılamazsanız, değerlendirici bunu ciddi bir eksiklik sayar.

Üçüncü örnek: bir süreç gereksinimini iyileştirmek¶

Fonksiyonel gereksinimlerin yanında süreç gereksinimleri de aynı disiplini ister. Kötü hâli:

"Kod incelemesi yapılmalıdır."

• Hangi değişiklik? (Her değişiklik mi, yalnız büyük olanlar mı?)
• Kim inceleyecek? (Yazarın kendisi sayılır mı?)
• Ne zaman? (Birleştirmeden önce mi, sonra mı?)

İyi hâli: "Her değişiklik, ana dala (main/master) birleştirilmeden önce, değişikliği yazan geliştirici dışında en az bir kişi tarafından incelenmeli ve inceleme onayı sürüm kontrol sisteminde kayıt altına alınmalıdır." Bu cümle artık doğrulanabilir: sürüm kontrol geçmişinde her birleştirme isteğinin (pull request) en az bir onay kaydı var mı diye bakılır — otomatik olarak bile denetlenebilir.

Gereksinimi yazmak yetmez: sıradaki soru "nasıl doğrularım?"¶

Bu bölümde bir gereksinimi iyi yazmayı öğrendik; ama iyi yazılmış bir gereksinim bile tek başına hiçbir şey kanıtlamaz. Bir sonraki soru her zaman şudur: "Bu gereksinimin karşılandığını hangi somut adımla gösteririm?" Bu soru bizi 2. bölümdeki izlenebilirlik zincirine götürür.

2. Gereksinimden kanıta: izlenebilirlik¶

Bir gereksinim ancak kanıtıyla karşılanmış sayılır. Bu disipline izlenebilirlik denir: her gereksinimi bir önleme, bir teste ve bir kanıta bağlamak; "bu gereksinim nerede karşılandı, nasıl doğrulandı?" sorusuna her zaman cevap verebilmektir. Sertifikasyonda her gereksinim için şu zincir kurulur:

Bu zincirin tablo haline uyum matrisi (compliance matrix) denir:

Matrisin iki yönü vardır: ileri izlenebilirlik (her gereksinim bir önleme ve teste gidiyor mu?) ve geri izlenebilirlik (her önlem bir gereksinime ya da tehdide dayanıyor mu, yoksa gereksiz mi?). Değerlendirici önce ileri yönü okur: karşılanmış denen ama kanıtı olmayan bir satır, ilk bulgudur.

İşlenmiş örnek: bir varlıktan kanıta, uçtan uca¶

Zincirin nasıl kurulduğunu tek bir varlık üzerinden başından sonuna kadar dolduralım.

1. Varlık (1. hafta varlık tablosundan).

2. Tehdit (1. hafta tehdit modelinden). Ağ üzerinde konumlanan bir saldırgan (ör. aynı halka açık Wi-Fi'de), şifrelenmemiş bir bağlantıdan belirteci dinleyip yakalayabilir ve kendi isteklerinde kullanarak kullanıcı gibi davranabilir (STRIDE: Spoofing + Information Disclosure, 1. hafta terminolojisi).

3. Gereksinim (bu haftanın konusu). Tehdide karşı sistemin ne yapması gerektiğini yazıyoruz; 1. bölümdeki altı adımı kısaca tekrar uyguluyoruz: varlık (oturum belirteci) → tehdit (ağ dinleme) → hedef (gizlilik + kimlik) → araç sınıfı (şifreli kanal + sunucu kimlik doğrulaması) → durum (aktarımda) → zorunluluk (MUST).

CEN429-DT-01 — "Oturum belirteci yalnız TLS 1.2 ve üzeri, sunucu sertifikası doğrulanmış bir kanaldan taşınmalıdır."

4. Önlem (kılavuzda hangi bölüm, ne yapılıyor). Kılavuzun S10.3 "Aktarım güvenliği" bölümünde: "İstemci, sunucuya her bağlantıda TLS 1.2+ el sıkışması yapar; sertifika zinciri ve ana bilgisayar adı doğrulanır (bkz. Hafta 10). Kanal kurulmadan hiçbir istek gönderilmez."

5. Doğrulama (nasıl test edildi). Güvenlik testi ekibi bir MITM (ortadaki adam) aracı ile bağlantıyı araya girmeye çalışır: (a) geçersiz/kendinden imzalı bir sertifika sunarak bağlantının reddedildiğini, (b) düz metin (TLS'siz) bağlantı denemesinin reddedildiğini doğrular.

6. Kanıt (nerede, kim tarafından üretildi). Test aracının günlük çıktısı (mitm_test_2026-11-03.log), CI çalıştırma kaydı (#617) ve bağlantı sırasında yakalanan TLS handshake paket dökümü (handshake.pcapng), proje deposunun evidence/week13/ klasöründe saklanır ve uyum matrisinde bu dosya adlarıyla referans verilir.

Bu altı adım tamamlandığında uyum matrisindeki satır şöyle dolar:

Zincirin altı halkasından biri eksik olsaydı ne olurdu?

• Varlık tanımsız olsaydı → gereksinimin "hangi veri" sorusuna cevabı olmazdı.
• Tehdit bağlanmasaydı → gereksinim keyfi görünürdü, "neden bu gereksinim var?" sorusuna cevap yoktu.
• Önlem yazılmasaydı → "karşılandı" iddiası desteksiz kalırdı.
• Doğrulama tanımlanmasaydı → "nasıl test edildi?" sorusuna cevap olmazdı.
• Kanıt olmasaydı → satır, değerlendiricinin ilk bulgusu olurdu (bkz. aşağıdaki kural).

Aynı gereksinim üzerinden "devredildi" durumunu da görelim: ürün bir kütüphane olsaydı ve TLS bağlantısını üst uygulama kuruyor olsaydı, CEN429-DT-01 üst uygulamaya devredilir ve S14'e "kime: üst uygulama; neden: kütüphane ağ bağlantısı açmıyor; nasıl: üst uygulama TLS 1.2+ ve sertifika doğrulamasıyla bağlanmalı" yazılırdı. Devretmenin kuralları §3'te.

Geri izlenebilirlik: fazladan bir önlem bulmak¶

İleri izlenebilirliği yukarıda gördük. Geri izlenebilirlik tam tersini sorar: kılavuzda yazan her önlem bir gereksinime dayanıyor mu? Diyelim ki kılavuzda şu cümle var: "Uygulama başlangıçta rastgele bir gecikme uygular." Bu önlem hangi gereksinime bağlanıyor? Eğer ekip bunun CEN429-AP-05 ("hata ayıklayıcı ve kanca algılandığında tanımlı bir tepki verilmelidir") gereksinimine dayandığını gösteremiyorsa, bu ya (a) tehdit modelinde eksik bir tehdit vardır (gecikme neden gerekliydi, hangi saldırıyı yavaşlatıyor?) ya da (b) önlem **gereksiz**dir ve kılavuzdan çıkarılmalıdır. Geri izlenebilirlik, kılavuzu şişiren ama hiçbir şeyi karşılamayan "kendiliğinden iyi fikir" önlemleri temizlemenin yoludur; her sayfa, değerlendiricinin okuması gereken bir sayfadır, gereksiz önlem değerlendirme süresini uzatır.

İzlenebilirlik ile 12. hafta değerlendirmesi arasındaki bağ¶

Geçen hafta (12. hafta) gördüğünüz değerlendirme süreci, aslında bu matrisin okunma biçimidir: bir değerlendirici projenizi incelerken rastgele kod satırlarını okumaz; önce uyum matrisini açar, "karşılandı" satırlarını seçer, her birinin kanıtını talep eder ve kanıtı bağımsız olarak doğrular (12. haftadaki "bağımsız doğrulama" ilkesi). Matrisiniz ne kadar iyi kurulmuşsa, değerlendirme o kadar hızlı ve o kadar az soru işaretiyle ilerler; kötü kurulmuş bir matris, değerlendiricinin her satırda durup "bunu nereden biliyoruz?" diye sormasına yol açar ve süreci uzatır.

İşlenmiş örnek: 'karşılanmadı' durumunun tam zinciri¶

Zincir yalnız "karşılandı" satırları için değil, "karşılanmadı" satırları için de kurulur — fark, son iki halkadadır.

Bu, dersin başındaki uyum matrisi tablosunda gördüğümüz CEN429-DT-04 satırının açılımıdır. "Karşılanmadı" durumunda önlem ve doğrulama sütunları boş kalabilir ama kanıt sütunu boş kalamaz — orada gerçek bir kanıt değil, kalan riskin nerede belgelendiği yazılır. Boş bırakmak, riskin unutulduğu izlenimini verir.

Neden 'liste' değil 'matris'?¶

Bir kontrol listesi (checklist) yalnız "yapıldı/yapılmadı" der. Uyum matrisi altı boyutu (kimlik, gereksinim, durum, önlem, doğrulama, kanıt) bir arada tuttuğu için "matris" denir: her satır bir gereksinim, her sütun izlenebilirlik zincirinin bir halkasıdır. Bir hücre eksikse, o satırın o boyutta doğrulanamaz olduğu anlamına gelir — liste bunu gösteremez, matris gösterir.

Değerlendiricinin sık yazdığı beş bulgu türü¶

Uyum matrisini okuyan bir değerlendirici genelde şu beş bulgu türünden birini yazar; kendi matrisinizi teslim etmeden önce bu beşini kontrol edin:

1. Kanıtsız "karşılandı". En sık görülen bulgu; bu bölümün ana kuralı.
2. Tutarsız kimlik. Aynı gereksinime kılavuzun farklı yerlerinde farklı kimlikler verilmiş (ör. bir yerde CEN429-DR-01, başka yerde DR01) — izlenebilirlik yazılım araçlarıyla otomatik kontrol edilemez hâle gelir.
3. Bağlanmamış önlem (geri izlenebilirlik). Kılavuzda bir önlem var ama hangi gereksinimi karşıladığı belirtilmemiş.
4. Gerekçesiz "uygulanmaz". Bu haftanın 0. ve 7. bölümlerinde işlenen hata.
5. Genel/kopyala-yapıştır kanıt. 8. bölümdeki işlenmiş örnekte görülen hata.

Demo aracı 01-uyum-matrisi yalnız birinci türü (kanıtsız "karşılandı") otomatik tarar; diğer dördü şu an için elle, bir değerlendirici gibi okuyarak bulunur.

İzlenebilirliği kod düzeyinde de sürdürmek¶

Uyum matrisi genelde ayrı bir belge (tablo) olarak tutulur, ama izlenebilirliği kaynak kodun içine de taşımak mümkündür ve büyük projelerde yaygındır: kritik bir fonksiyonun üstüne "bu fonksiyon CEN429-DR-01'i karşılar" biçiminde bir yorum satırı eklemek, kodu okuyan bir sonraki geliştiricinin (ya da bir yıl sonraki kendinizin) "bu satır neden burada?" sorusuna anında cevap bulmasını sağlar. Bu, 3. bölümdeki gereksinim bloğunun kod tarafındaki küçük bir yansımasıdır:

/* CEN429-DR-01: beklemedeki kasa dosyası AEAD ile şifrelenir. */
int kasa_dosyasi_sifrele(const unsigned char *anahtar, ...) {
    ...
}

Böyle bir yorum, kanıt sütununun yerine geçmez (kanıt hâlâ bir test/kayıt olmalıdır) ama gereksinim ile kodu birbirine görsel olarak bağlar; kod incelemesi yapan biri, gereksinimi karşılayan kodu ararken bu yorumları tarayabilir.

3. Gereksinim bloğu kalıbı ve devredilen gereksinimler¶

Kılavuzda gereksinim bloğu¶

Sertifikasyondan geçen güvenlik kılavuzlarında her bölüm, o bölüme düşen gereksinimlerle açılır. Her gereksinim şu kalıpta yazılır:

[Standart/şema] Gereksinim kimliği — DURUM
Gereksinimin metni (standarttan).
Ürünün bu gereksinimi nasıl karşıladığının açıklaması; ilgili önlem kartlarına ve bölümlere başvuru.

Sahada bir mobil ödeme kütüphanesinin kılavuzunda "beklemede veri", "kullanımda veri", "aktarımda veri", "raporlama", "kripto yöntemleri ve anahtarlar" gibi her bölüm, iki kart şemasının bu konudaki gereksinimleriyle açılır ve her biri karşılandı ya da üst uygulamaya devredildi olarak işaretlenir. Bu kalıbın gücü, değerlendiricinin gereksinimden kanıta tek bakışta gidebilmesidir.

Devredilen gereksinimler: sorumluluğun sınırı¶

Bir yazılım bileşeni (ör. başka uygulamaların içine gömülen bir kütüphane) her gereksinimi tek başına karşılayamaz. Uygulamanın kurulması, güncellenmesi, kullanıcıya bildirim göstermesi ya da kendi kaynak kodunu koruması, bileşenin değil onu kullanan uygulamanın işidir. Bu gereksinimler devredilir ve kılavuzun "dış bileşenlerden beklenen güvenlik" bölümünde açıkça yazılır.

Proje için: S14 "Varsayımlar ve devredilen gereksinimler"¶

Projeniz tek başına çalışan bir uygulama olsa bile varsayımları vardır: desteklenen işletim sistemleri, kullanıcının yönetici olmadığı, derleme ortamının güvenilir olduğu, sunucunun ayrı bir ekip tarafından korunduğu. Bunları açıkça yazmak, değerlendiricinin kapsamı doğru anlamasını sağlar ve "bu tehdit neden kapsam dışı?" sorusunu önceden cevaplar.

İşlenmiş örnek: gereksinim bloğunu baştan sona doldurmak¶

Kalıbı gerçek bir örnekle dolduralım; bu, 2. bölümdeki CEN429-DR-01 zincirinin kılavuza yazılmış hâlidir:

[CEN429-DR] CEN429-DR-01 — KARŞILANDI
Gereksinim: Beklemedeki C sınıfı hassas veri, kimlik doğrulamalı şifrelemeyle (AEAD) korunmalıdır.
Karşılama: Yerel kasa dosyası AES-256-GCM ile şifrelenir (bkz. S7.2 "Kasa dosyası şifreleme"). Şifreleme
anahtarı, cihazın güvenli depolama biriminden (Android Keystore / iOS Keychain) türetilir ve bellek dışında
düz metin olarak hiç saklanmaz. Doğrulama: birim testi (test_butunluk.c), şifreli dosyanın tek baytını
değiştirip çözmenin reddedildiğini kontrol eder. Kanıt: CI çalıştırma kaydı #482, test çıktısı
evidence/week13/test_butunluk_ci482.log.

Bloğun her satırı bir amaca hizmet eder: başlık satırı ([Aile] Kimlik — Durum) değerlendiricinin gözünü hızlıca nereye götüreceğini söyler; Gereksinim satırı standarttan ya da tehdit modelinden gelen "ne"yi tekrarlar (kopyala-yapıştır, yeniden yorumlanmaz); Karşılama paragrafı "nasıl"ı, somut dosya ve bölüm adlarıyla anlatır; Doğrulama ve Kanıt cümleleri 2. bölümdeki zincirin son iki halkasını tamamlar.

Şimdi aynı kalıbı bir devredilen gereksinim için dolduralım — bu kez ürünün kendisi değil üst uygulama karşılıyor:

[CEN429-AP] CEN429-AP-07 — DEVREDİLDİ (üst uygulamaya)
Gereksinim: Uygulama güvenli biçimde kurulmalı ve güncellenmelidir.
Karşılama: Kütüphane kendi başına bir dağıtım/güncelleme mekanizmasına sahip değildir; bu, kütüphaneyi
paketleyen üst uygulamanın sorumluluğundadır. Üst uygulama geliştiricisine önerilen yöntem: (1) resmî
uygulama mağazasının imza doğrulamasını kullanmak, (2) kendi güncelleme kanalı kullanılıyorsa güncelleme
paketlerini Hafta 6'da anlatılan imzalama şemasıyla imzalamak. Kime: üst uygulama geliştiricisi. Neden:
kütüphane ağ/dosya sistemi seviyesinde kurulum işlemine erişmez, yalnız API olarak çağrılır. Nasıl:
yukarıdaki iki yöntemden biri, kılavuzun "Dış bileşenlerden beklenen güvenlik" bölümünde ayrıntılandırılır.

Dikkat edin: "devredildi" bloğu da Karşılama alanına sahiptir — ama bu alan "biz nasıl yaptık" değil "karşı taraf nasıl yapmalı ve biz bunu neden kendimiz yapmıyoruz" sorularını cevaplar. Devretmek, o alanı boş bırakmak değildir; tam tersine daha fazla açıklama ister, çünkü sorumluluk sınırının nerede olduğunu kanıtlamanız gerekir.

S14'ü doldururken sık karşılaşılan üç varsayım¶

Projeler genelde şu üç varsayımı unutur; S14'e eklerken kontrol edin:

1. Derleme ortamı güvenilir mi? "Derleme sunucusuna saldırgan erişemez" varsayımı genelde yazılmaz ama her projenin dayandığı bir temeldir (6. hafta tedarik zinciri güvenliği).
2. Kullanıcı cihazı kök/jailbreak yapılmamış mı? Yapılmışsa hangi önlemlerin geçersiz kaldığı (ör. güvenli depolama artık güvenli olmayabilir) açıkça yazılmalıdır.
3. Sunucu tarafı ayrı bir ekip tarafından mı korunuyor? Öyleyse hangi gereksinimlerin (ör. sunucu tarafı erişim denetimi) bu projenin kapsamı dışında olduğu net yazılmalıdır; aksi hâlde değerlendirici bunları da bu projeden bekler.

Neden devretmek kötü bir şey değildir (gerekçe)¶

Yeni geliştiriciler "devretmek" kelimesini bir zayıflık gibi algılar ve her şeyi kendi bileşenlerinde karşılamaya çalışır — bu da genelde bileşenin yapamayacağı işleri (kurulum, işletim sistemi düzeyinde izolasyon, kullanıcı arayüzü uyarıları) üstlenmeye çalışmasına, ya da daha kötüsü, bu işleri hiç ele almadan sessizce atlamasına yol açar. Sertifikasyon dünyasında sınırları açıkça çizmek, sınırları belirsiz bırakmaktan her zaman daha iyi bir puan alır: bir değerlendirici, kime ne devredildiğini bilen bir kılavuza güvenir; "her şeyi biz hallederiz" diyen ama kanıt sunamayan bir kılavuza güvenmez.

İşlenmiş örnek: 'karşılanmadı' durumunda gereksinim bloğu¶

Bazı gereksinimler henüz ne karşılanmış ne de devredilmiştir — proje bilinçli olarak bu riski taşımaya karar vermiştir. Bloğun bu durumdaki hâli:

[CEN429-DT] CEN429-DT-04 — KARŞILANMADI
Gereksinim: Sunucu sertifikası sabitlenmelidir (certificate pinning).
Durum: Şu anda uygulanmıyor; yalnız standart TLS sertifika zinciri doğrulaması yapılıyor (CEN429-DT-01
karşılanıyor, ama sabitleme yok). Kalan risk: bir saldırganın, güvenilir bir kök sertifika yetkilisinden
sahte bir sertifika alabilmesi durumunda MITM mümkün olabilir (bkz. S16.4). Planlanan düzeltme: v1.1
sürümünde sabitleme eklenecek (bkz. proje planı, görev #217).

"Karşılanmadı" bloğu Karşılama yerine Durum ve Kalan risk alanlarını doldurur; bu, gereksinimin gelecekte karşılanacağını ama şu an karşılanmadığını dürüstçe belirtir. Bunu hiç yazmamak (satırı matristen çıkarmak) daha kötüdür: değerlendirici gereksinimi kendisi bulur ve "bunu neden atladınız?" diye sorar.

Zor bir devretme kararı: donanım ne zaman devreder, ne zaman devretmez?¶

"Donanım güvenli elemanı (secure element/TEE) yoksa gereksinim donanıma devredilemez" — bu basit kural bazen yanlış uygulanır. Örneğin "anahtar fiziksel saldırıya karşı korunmalıdır" gereksinimini ele alalım:

• Cihazda bir güvenli eleman varsa: gereksinim donanıma devredilebilir; kılavuzda "anahtar üretimi ve saklaması cihazın güvenli elemanına devredilmiştir, uygulama yalnız API'yi çağırır" yazılır.
• Cihazda güvenli eleman yoksa: gereksinim devredilemez, çünkü devredilecek bir taraf yoktur. Bu durumda ürünün kendisi yazılım tabanlı bir önlem (ör. beyazkutu kriptografi, kod gizleme) uygulamalı ya da gereksinimi "karşılanmadı" olarak işaretleyip kalan riski yazmalıdır.

Yaygın hata, ikinci durumda da "donanıma devredildi" yazmaktır — devredilecek somut bir taraf olmadığı için bu geçersiz bir devretmedir ve değerlendirici tarafından reddedilir.

4. Ortak Kriterler (ISO/IEC 15408)¶

Ortak Kriterler (Common Criteria, CC), BT ürünlerinin güvenlik değerlendirmesi için uluslararası standarttır. Değerlendirme yöntemi ayrı bir belgede (CEM, ISO/IEC 18045) tanımlanır. Ortak Kriterleri Tanıma Anlaşması (CCRA) sayesinde bir ülkede verilen sertifika, anlaşmaya taraf diğer ülkelerde de tanınır.

Temel kavramlar¶

EAL düzeyleri¶

EAL yüksekliği ürünün "daha güvenli" olduğu anlamına gelmez; değerlendirmenin daha derin yapıldığı anlamına gelir. EAL4 bir ürün, EAL2 bir üründen daha güvensiz olabilir; önemli olan ST'deki güvenlik amaçlarının ve tehditlerin kapsamıdır. "+" işareti (EAL4+), pakete ek güvence bileşenleri eklendiğini gösterir; en sık eklenen, zafiyet değerlendirmesinin derinliğini artıran bileşendir.

Zafiyet değerlendirmesi ve saldırı potansiyeli¶

CC'nin zafiyet değerlendirmesi bileşeni (AVA_VAN), ürünün hangi saldırı potansiyeline sahip bir saldırgana karşı dayanması gerektiğini belirler: temel (Basic), gelişmiş temel (Enhanced-Basic), orta (Moderate) ve yüksek (High). Saldırı potansiyeli CEM'de beş etkenle puanlanır: geçen süre, uzmanlık, ürün hakkında bilgi, fırsat penceresi ve ekipman. Puanların toplamı, başarılı bir saldırının hangi potansiyel düzeyini gerektirdiğini gösterir; ürün, ST'de iddia ettiği düzeyin altındaki saldırganlara karşı dayanmalıdır. Ödeme ürünlerinin değerlendirmelerinde de aynı fikrin uyarlanmış biçimleri kullanılır.

İşlenmiş örnek: projeniz için bir ST iskeleti doldurmak¶

Bir güvenlik hedefi (ST) baştan yazmak korkutucu görünebilir; aslında dönem boyunca topladığınız belgelerin yeniden düzenlenmesidir. Aşağıda örnek bir mobil ödeme bileşeni için üç adımda dolduruyoruz.

Adım 1 — TOE'yi tanımlayın (neyi değerlendiriyoruz, neyi değerlendirmiyoruz).

TOE: "CEN429-Pay" kütüphanesi, sürüm 1.0, yalnız Android ARM64 derlemesi. Kapsam dışı: üst uygulamanın kullanıcı arayüzü, sunucu tarafı bileşenler, işletim sistemi çekirdeği.

TOE'yi tanımlarken kapsam dışını yazmak en az kapsamı yazmak kadar önemlidir — 3. bölümdeki "devredilen gereksinimler" fikriyle doğrudan bağlantılıdır: kapsam dışı bırakılan her şey, ST'de "varsayım" olarak yeniden karşımıza çıkar.

Adım 2 — Tehditleri ve varsayımları listeleyin (1. hafta tehdit modelinden).

Adım 3 — Güvenlik amaçlarını ve karşılık gelen SFR ailelerini eşleyin.

Bu tablo, ST'nin kalbidir: her satır "neden bu gereksinim var" (tehdit) ile "hangi kanıt istenir" (SFR ailesi, sonra SAR ile test edilir) arasındaki köprüdür. Hedef EAL'i seçmek son adımdır: bu proje için ekip "ticari ürünlerde en yaygın üst düzey" olan EAL4 benzeri bir güvence derinliğini hedef olarak seçebilir (gerçek bir CC değerlendirmesi yaptırmadan, yalnız kendi iç disiplinini o seviyeye göre kurmak için).

CC'nin kökeni: neden birden fazla ülke aynı standardı kullanıyor?¶

Ortak Kriterler'den önce ABD, Avrupa ve Kanada'nın kendi ayrı değerlendirme ölçütleri vardı (ABD'de Orange Book/TCSEC, Avrupa'da ITSEC, Kanada'da CTCPEC). Her ülke kendi ölçütüne göre sertifika verdiği için, bir ülkede sertifikalı bir ürün başka bir ülkede yeniden değerlendirilmek zorunda kalıyordu. Ortak Kriterler bu üç yaklaşımı birleştirerek tek bir uluslararası standart (ISO/IEC 15408) hâline getirdi; CCRA (Ortak Kriterleri Tanıma Anlaşması) sayesinde bir ülkedeki sertifika, anlaşmaya taraf diğer ülkelerde tekrar değerlendirmeye gerek kalmadan tanınır. Bu, tıpkı farklı ülkelerin farklı priz standartları yerine tek bir ortak standarda geçmesi gibidir: uyumluluk maliyeti düşer, karşılaştırma kolaylaşır.

SFR'ler neden uydurulmaz, katalogdan seçilir¶

Ortak Kriterler'in ilgili bölümünde önceden tanımlanmış bir SFR kataloğu vardır (FCS, FDP, FIA, FAU, FMT, FPT, FTP gibi aileler ve bunların alt bileşenleri). Bir ST yazarken yeni bir SFR icat etmek yerine bu katalogdan seçim yapılır; katalogda tam karşılığı olmayan bir ihtiyaç varsa "genişletilmiş bileşen" olarak ayrıca tanımlanıp gerekçelendirilir. Bunun nedeni tutarlılıktır: iki farklı ürünün ST'si aynı kataloğu kullanırsa, bir değerlendirici ikisini karşılaştırabilir; her ürün kendi terminolojisini uydursaydı karşılaştırma imkânsız olurdu.

EAL seçimi: pratik bir karar rehberi¶

Öğrenciler sık sık "projemiz için hangi EAL'i yazmalıyız?" diye sorar. Gerçek bir CC sertifikasyonu yaptırmayacaksanız bile (ki dönem projesi için yaptırmayacaksınız), EAL kavramını iç disiplin hedefi olarak kullanmak faydalıdır:

Bu tablo bir CC sertifikası vaat etmez; yalnızca "ne kadar titiz belgeleme ve test sürecine ihtiyacımız var" sorusuna kaba bir kıyas sunar.

PP ile ST'yi yeniden kullanmak¶

Bir ürün sınıfı için PP zaten varsa (ör. "mobil cihaz" ya da "güvenlik duvarı" PP'leri), yeni bir ürün geliştiren ekip ST'sini sıfırdan yazmaz; PP'nin gereksinimlerini alır, kendi TOE'sine uyarlar ve "bu PP'ye uyduğumuzu iddia ediyoruz" der. Bu, 8. bölümdeki dersin gereksinim ailelerinin mantığıyla aynıdır: PP bir şablon, ST o şablonun belirli bir ürüne uygulanmış hâlidir. Kendi projeniz için dersin gereksinim aileleri, gayrı resmî bir "mini PP" gibi düşünülebilir.

CC süreci ile 12. haftanın değerlendirme sürecini karşılaştırmak¶

Geçen hafta (12. hafta) gördüğünüz bağımsız değerlendirme adımları (belge incelemesi, kod incelemesi, test tekrarı, zafiyet analizi) aslında CC'nin CEM'de tanımladığı değerlendirme faaliyetlerinin ders ölçeğine indirgenmiş hâlidir: CC'de ADV (geliştirme) belgeleri incelenir, ATE (test) sonuçları bağımsız olarak tekrarlanır, AVA (zafiyet değerlendirmesi) ile saldırı potansiyeli analiz edilir. Akredite bir laboratuvar aylarca süren bu süreci, sizin geçen haftaki bir oturumluk değerlendirmeniz küçük ölçekte taklit eder — aynı disiplin, farklı ölçek.

5. FIPS 140-3: kriptografik modüllerin doğrulanması¶

FIPS 140-3, ABD NIST'in kriptografik modüller için güvenlik standardıdır; içeriği uluslararası ISO/IEC 19790 standardına dayanır. Doğrulama, NIST ile Kanada'nın ortak yürüttüğü Kriptografik Modül Doğrulama Programı (CMVP) kapsamında, akredite laboratuvarlarca yapılır. Kitabın Tarif 11.18'de andığı FIPS 140-1/140-2'nin yerini almıştır; FIPS 140-2 sertifikaları 2026 itibarıyla tarihsel listeye alınmaktadır.

Güvenlik düzeyleri¶

Bir modülün FIPS 140-3'te yapması gerekenler (özet)¶

• Yalnız onaylı algoritmaları (AES, SHA-⅔, HMAC, RSA, ECDSA, onaylı rastgele üreteçler; 2024'ten itibaren kuantum sonrası algoritmalar) "onaylı kip"te kullanmak; her algoritmanın ayrıca algoritma doğrulama programından (CAVP) sertifikası olması.
• Açılışta ve koşullu öz testler yapmak (bilinen cevap testleri, bütünlük denetimi); başarısızsa hata durumuna geçip kripto hizmeti vermemek.
• Roller ve hizmetler tanımlamak (kullanıcı, yetkili); her hizmetin hangi kritik güvenlik parametresine (anahtar) eriştiğini belgelemek.
• Kritik güvenlik parametrelerini güvenli üretmek, girip çıkarmak ve iş bitince sıfırlamak (zeroization).
• Bir güvenlik politikası belgesi yayımlamak.

İşlenmiş örnek: bir modülü FIPS 140-3 düzey 1'e göre denetlemek¶

Yukarıdaki "özet" listesini gerçek (ama basitleştirilmiş) bir projeye uygulayalım. Diyelim ki projenizin kripto katmanı şöyle: OpenSSL'in standart EVP arayüzünü kullanıyor, AES-256-GCM ile şifreliyor, anahtarları getrandom()'dan üretiyor (3. hafta), hata durumunda sessizce varsayılan bir anahtara düşüyor. Düzey 1 beklentilerini tek tek işaretleyelim:

Bu tablo, projenin FIPS 140-3 düzey 1'den bile uzak olduğunu, en kritik açığın "hata durumunda sessizce varsayılan anahtara düşmek" olduğunu gösterir — bu, tam olarak sıfırlama (zeroization) ilkesinin tersidir ve 3. haftada gördüğümüz "rastgele üreteç başarısız olursa dur, devam etme" kuralının ihlalidir.

FIPS doğrulama sürecinin adımları (kabaca)¶

Bir kriptografik modülü FIPS 140-3'e göre doğrulatmak, tek seferlik bir onay değil, adımlı bir süreçtir:

1. Geliştirici modülü onaylı algoritmalarla, güvenlik politikası belgesiyle birlikte hazırlar.
2. CAVP (Cryptographic Algorithm Validation Program) her algoritmanın (AES, SHA-2, HMAC, RSA...) ayrı ayrı doğru uygulandığını test eder ve algoritma sertifikası verir.
3. Akredite laboratuvar, modülü FIPS 140-3'ün fiziksel, mantıksal ve süreç gereksinimlerine göre test eder.
4. CMVP, laboratuvarın raporunu inceler ve modül sertifikasını yayımlar; sertifika modülün tam sürümünü ve çalıştığı platformu belirtir.
5. Modül ya da platform değişirse (ör. yeni bir işletim sistemi sürümü), sertifika yeniden doğrulama gerektirebilir.

Bu adım sırası, "AES kullanıyoruz" cümlesinin FIPS iddiası için neden yetersiz olduğunu gösterir: 2. adım yalnız algoritmayı, 3-4. adımlar ise bütün modülü (algoritma + öz testler + roller + sıfırlama) kapsar. Sertifika, 4. adım tamamlanmadan verilmez.

Bir CMVP sertifikasında ne yazar?¶

Gerçek bir CMVP sertifikası genel olarak şunları belirtir: modülün adı ve sürümü, hangi işletim sistemi/donanım üzerinde test edildiği, hangi güvenlik düzeyinde doğrulandığı ve doğrulanan algoritmaların CAVP sertifika numaraları. Bir proje "FIPS doğrulanmış X kütüphanesini kullanıyoruz" derken, aslında bu sertifikadaki tam sürüm ve platform eşleşmesinin kendi ürünündeki kullanımla birebir aynı olduğunu kontrol etmelidir; sertifika Linux x86-64 için verilmişse, aynı kütüphanenin Android ARM derlemesi aynı sertifikayı otomatik miras almaz.

FIPS düzeyleri ile CC EAL'i karıştırmayın¶

Her ikisi de küçük sayılarla (1'den 4'e ya da 1'den 7'ye) ifade edildiği için öğrenciler bu iki ölçeği karıştırır:

Bir ürün aynı anda hem "FIPS 140-3 düzey 2" hem "CC EAL4" iddia edebilir — bunlar birbirini dışlamaz, farklı boyutları ölçer. Biri diğerinin yerine geçmez.

FIPS uyumluluğunu iddia etmeden önce sorulacak üç soru¶

Projenizde bir FIPS iddiası yazmadan önce şu üç soruyu sırayla sorun:

1. Hangi modülün sertifikası var — işletim sisteminin kripto kütüphanesi mi, uygulamanın gömdüğü ayrı bir kütüphane mi?
2. Bu sertifika sizin kullandığınız tam sürüm ve platformu kapsıyor mu (yukarıdaki "platform/sürüm uyuşmazlığı" hatası)?
3. Kullandığınız her algoritma çağrısı, modülün "onaylı kip"inde mi çalışıyor, yoksa modülün onaylanmamış bir yardımcı fonksiyonunu mu kullanıyorsunuz?

Üç soruya da "evet" diyemiyorsanız, iddianızı "FIPS onaylı algoritmalar kullanıyoruz" gibi daha dar, dürüst bir cümleye indirin (bu bölümün başındaki uyarı kutusunda görüldüğü gibi).

Bu haftanın demosuyla bağlantı¶

Bu haftanın 01-uyum-matrisi demosu, kanıtsız "karşılandı" satırlarını otomatik bulur; bir FIPS iddiasının kanıtsız yazılması da aynı sınıfta bir hatadır. Kendi projenizde "FIPS 140-3'e uyumluyuz" gibi bir cümle yazıyorsanız, bunu uyum matrisinizde ayrı bir satır olarak ele alın ve kanıt sütununa sertifika numarasını (ya da "sertifika yok, yalnız onaylı algoritma kullanıyoruz" dürüstlüğünü) yazın.

6. ETSI, GSMA, EMVCo, PCI ve OWASP: sektöre özgü gereksinim setleri¶

ETSI EN 303 645: tüketici nesnelerin interneti¶

Avrupa Telekomünikasyon Standartları Enstitüsü'nün (ETSI) bu standardı, internete bağlanan tüketici cihazları için temel bir güvenlik çizgisi tanımlar ve Avrupa'daki düzenlemelerin dayanağı olmuştur. On üç başlığı, dönem boyunca gördüğümüz konuların kısa bir özeti gibidir:

GSMA¶

Mobil operatörlerin birliği GSMA, IoT cihazları ve hizmetleri için IoT Güvenlik Yönergeleri'ni, SIM ve eSIM üretimi ile abonelik yönetimi tesisleri için Güvenlik Akreditasyon Şeması'nı (SAS) ve ağ ekipmanları için bir değerlendirme şemasını (NESAS) yürütür. SAS, ürünün değil üretim ve yönetim tesisinin denetlenmesine bir örnektir: fiziksel güvenlik, personel, süreçler, anahtar yönetimi.

EMVCo ve PCI: ödeme¶

Yukarıdaki EMVCo aile listesine dikkat edin: dönem boyunca her haftanın konusu bu ailelerden birine karşılık geliyordu. Dersin gereksinim aileleri (8. bölüm) bu yapıdan uyarlanmıştır.

OWASP MASVS: uygulanabilir bir kontrol listesi¶

Resmî bir sertifika vermese de OWASP'ın Mobil Uygulama Güvenliği Doğrulama Standardı (MASVS), mobil uygulamalar için en yaygın kullanılan açık kontrol listesidir. Kontrol grupları: depolama (MASVS-STORAGE), kripto (MASVS-CRYPTO), kimlik doğrulama (MASVS-AUTH), ağ (MASVS-NETWORK), platform (MASVS-PLATFORM), kod (MASVS-CODE), dayanıklılık (MASVS-RESILIENCE) ve gizlilik (MASVS-PRIVACY). Test yöntemleri ayrı bir rehberde (MASTG) verilir. Dayanıklılık grubu, 4., 5., 6. ve 9. haftaların konularını kapsar.

İşlenmiş örnek: aynı gereksinimin dört standarttaki karşılığı¶

Standartlar birbirinden bağımsız yazılmış olsa da genelde aynı güvenlik ihtiyacını farklı sözcüklerle ifade eder. İki gereksinimi, dört standart boyunca izleyelim.

Örnek 1 — Beklemedeki hassas veri şifrelemesi

Örnek 2 — Varsayılan/zayıf kimlik doğrulamanın engellenmesi

Bu iki tablonun gösterdiği şey şudur: bir ürün EMVCo/PCI belgesi için "beklemede veri şifreleme" gereksinimini karşılayacak kanıtı zaten hazırlamışsa, aynı kanıtın büyük kısmı MASVS-STORAGE denetiminde de yeniden kullanılabilir — çünkü ikisi de aynı temel ihtiyacı (şifrelenmiş, sıfırlanabilir, sızdırmayan depolama) sorar. Ama "yeniden kullanılabilir" demek "otomatik karşılanır" demek değildir; her standardın kendi ölçütü (ör. MASVS ayrıca anahtarın işletim sisteminin güvenli depolama API'siyle korunmasını da ister) ayrı doğrulanmalıdır.

Standartları nasıl seçer, nasıl önceliklendirirsiniz?¶

Bir proje bu beş kaynağın (CC, FIPS, ETSI, GSMA/EMVCo/PCI, MASVS) hepsine birden uymaya çalışmaz; hangi standardın uygulanacağı ürünün türüne ve pazarına bağlıdır:

• Tüketici IoT cihazı satıyorsanız → ETSI EN 303 645 (bazı pazarlarda yasal zorunluluk).
• Mobil uygulama geliştiriyorsanız → OWASP MASVS (fiilî endüstri standardı, sertifika şartı olmasa da).
• Ödeme işleyen bir uygulama/kütüphaneyseniz → EMVCo ve/veya PCI belgeleri (kart şemalarının şartı).
• Devlet/savunma alıcısına satış yapıyorsanız → Ortak Kriterler sertifikası (çoğu zaman ihale şartı).
• Kriptografik bir modül/kütüphane satıyorsanız → FIPS 140-3 (ABD federal alıcılar için zorunlu).

Dersin gereksinim aileleri (8. bölüm) bu beşinden ortak paydaları çıkarır; kendi projenizde hangi sektöre girdiğinizi belirleyip S1 (kaynaklar) bölümünde hangi standartlara dayandığınızı açıkça yazmanız beklenir.

İşlenmiş örnek: ETSI EN 303 645 madde 5.13'ü projeye uygulamak¶

Madde 5.13 "girdi verisini doğrulamak" der; bunu 4. ve 5. haftalarda gördüğümüz girdi doğrulama/temizleme konusuyla birebir eşleyelim:

1. Madde: "Cihaz yazılımı, kullanıcı arayüzlerinden veya ağdan gelen verinin doğrulanması yoluyla verinin bozulmasını veya cihazın çökmesini önlemelidir."
2. Dersin gereksinimi: Bu madde, dersin CEN429-AP ailesine ya da yeni bir girdi doğrulama ailesine uyarlanabilir: "Ağdan veya kullanıcıdan gelen her girdi, işlenmeden önce uzunluk, tip ve aralık kontrolünden geçirilmelidir (bkz. Hafta 4–5)."
3. Önlem: Kılavuzda hangi ayrıştırma (parsing) fonksiyonlarının sınır denetimi yaptığı listelenir.
4. Doğrulama: Bulanıklaştırma (fuzzing) testi ya da sınır değer testleriyle geçersiz girdilerin güvenle reddedildiği gösterilir (Hafta 4'teki bulanıklaştırma demosuna bağlanır).
5. Kanıt: Fuzz testi çalıştırma raporu, çökme (crash) sayısının sıfır olduğunu gösteren özet.

Bu örnek, ETSI maddesinin soyut cümlesinin nasıl somut bir dersin gereksinimine, önlemine ve testine dönüştüğünü gösterir — tıpkı 2. bölümdeki izlenebilirlik zincirinde olduğu gibi.

GSMA NESAS ve PCI DSS düzeyleri hakkında kısa not¶

• GSMA NESAS (Network Equipment Security Assurance Scheme), mobil şebeke ekipmanı üreticilerinin güvenli geliştirme süreçlerini ve ürünlerinin güvenlik testlerini değerlendirir; SAS'ın (tesis odaklı) aksine hem süreç hem ürün odaklıdır.
• PCI DSS, kart verisi işleyen kuruluşları işlem hacimlerine göre düzeylere ayırır (en yüksek hacimli kuruluşlar en sıkı denetime tabidir); bu ders kapsamında düzey ayrıntılarına girmiyoruz, ama "büyüklüğe göre denetim sıklığı/derinliği değişir" fikri CC'deki EAL mantığıyla benzerdir: risk ne kadar büyükse, güvence o kadar derin olmalıdır.

Sektör setlerini karşılaştırmalı özetleyen bir tablo¶

Bu tablo, dersin en başında sorduğumuz "kim, neyi, nasıl sertifikalıyor?" sorusunun bu haftaki cevabıdır ve 6. bölümü kapatan bir özet görevi görür.

Bir ürün birden fazla sette birden yer alabilir mi?¶

Evet, hatta çoğu gerçek ürün öyledir. Örneğin bir mobil ödeme uygulaması aynı anda şunları hedefleyebilir: kart şemasının EMVCo gereksinimlerini (çünkü kart verisiyle çalışıyor), OWASP MASVS'yi (çünkü bir mobil uygulama) ve kullandığı kripto kütüphanesi üzerinden dolaylı olarak FIPS 140-3'ü (çünkü o kütüphane FIPS doğrulanmış olabilir). Bu ürün için Ortak Kriterler sertifikası genelde gerekli değildir çünkü CC daha çok devlet/savunma alıcıları tarafından istenir, tüketici ödeme uygulamalarında nadiren aranır. Kendi projeniz için de aynı analiz geçerlidir: "biz hangi pazara satıyoruz, o pazar hangi standardı arıyor?" sorusunun cevabı, hangi standartları S1'e yazacağınızı belirler — hepsini yazmak zorunda değilsiniz, yalnız ilgili olanları.

7. Gereksinimleri yazılım planına ve varlık yönetimine aktarmak¶

Bir gereksinim setini okumak işin kolay kısmıdır. Asıl iş, onu ürünün planına dönüştürmektir. Adımlar:

1. Uygulanabilirlik: Setteki her gereksinim için "bu ürüne uygulanır mı?" sorusu sorulur. Uygulanmayanlar gerekçesiyle işaretlenir (ör. "ürün ağ bağlantısı kullanmaz, aktarımda veri gereksinimleri uygulanmaz").
2. Sorumluluk: Uygulananlar "biz karşılarız" ve "devrederiz" olarak ayrılır (3. bölüm).
3. Varlıklara bağlama: Her gereksinim, varlık tablosundaki ilgili varlıklara bağlanır. "Kripto anahtarları iş bitince silinmeli" gereksinimi, varlık tablosundaki her anahtarın "oluşma → silinme" sütununun dolu olmasını gerektirir.
4. Tehditlere bağlama: Her gereksinim en az bir tehdide karşılık gelmelidir; karşılık gelmiyorsa ya tehdit modeli eksiktir ya da gereksinim bu ürün için gereksizdir.
5. Önlem ve doğrulama: Her gereksinim için önlem kartı ve doğrulama yöntemi (test, inceleme, analiz) planlanır.
6. Sürüm planı: Hangi gereksinimin hangi sürümde karşılanacağı proje planına işlenir; karşılanamayanlar kalan riske yazılır.

İşlenmiş örnek: altı adımı tek bir gereksinimde uygulamak¶

Bu bölümün başındaki altı adımı (uygulanabilirlik → sorumluluk → varlıklara bağlama → tehditlere bağlama → önlem ve doğrulama → sürüm planı), CEN429-CR-03 ("anahtarlar iş bitince silinmelidir") gereksinimi üzerinden uçtan uca uygulayalım.

1. Uygulanabilirlik. Proje kripto anahtarı kullanıyor mu? Evet — oturum anahtarı ve kasa dosyası anahtarı var. Gereksinim uygulanır.

2. Sorumluluk. Anahtarı üreten ve kullanan kod projenin kendi kodu; devretmek için bir neden yok. Ekip biz karşılarız kararını verir.

3. Varlıklara bağlama. Varlık tablosunda (S5) iki anahtar satırı var: "oturum anahtarı" ve "kasa dosyası anahtarı". Her ikisinin de "oluşma → kullanım → silinme" sütunu doldurulmalı; şu an "kasa dosyası anahtarı" satırında silinme zamanı boş. Bu eksiklik burada fark edilir.

4. Tehditlere bağlama. Hangi tehdit bu gereksinimi gerektiriyor? 1. haftanın tehdit modelinde "cihaza fiziksel erişimi olan saldırgan bellek dökümü (memory dump) alır" tehdidi var; anahtar iş bittikten sonra bellekte kalırsa bu tehdit gerçekleşebilir. Gereksinim bu tehdide bağlanır; bağlanamasaydı ya tehdit modeli eksikti ya da gereksinim bu ürün için gereksizdi (yukarıdaki 4. madde).

5. Önlem ve doğrulama. Önlem: anahtar kullanımdan hemen sonra sifreleme_bellek_sil() çağrılır (sıfırlarla üzerine yazma, derleyicinin bu çağrıyı optimize ederek silmediğinden emin olunur — 9. hafta koruma kurallarına bağlanır). Doğrulama: bellek analiz aracı (ör. bir bellek dökümü alıp anahtar baytlarını aramak) ile anahtarın iş bitiminden sonra bellekte bulunmadığı doğrulanır.

6. Sürüm planı. Oturum anahtarı için bu önlem zaten v0.9'da var (karşılandı). Kasa dosyası anahtarı için eksik; ekip bunu v1.0 sürüm planına ekler ve o güne kadar durumu uyum matrisinde karşılanmadı, kalan riske "kasa dosyası anahtarı iş bitiminde bellekte kalabilir, düzeltme v1.0'da" olarak yazar.

Altı adımın sonunda hem uyum matrisi satırı hem de proje planındaki bir görev (kasa dosyası anahtarını v1.0'da sıfırlama) ortaya çıkmış olur — bu, "gereksinimi okumak" ile "gereksinimi projeye dönüştürmek" arasındaki farktır.

İkinci örnek: aynı altı adımı bir süreç gereksinimine uygulamak¶

Adımlar yalnız teknik gereksinimler için değil, süreç gereksinimleri için de aynı şekilde işler. CEN429-DV-02 ("her değişiklik incelenmelidir") üzerinden hızlıca geçelim:

1. Uygulanabilirlik: Proje bir sürüm kontrol sistemi kullanıyor mu? Evet → uygulanır.
2. Sorumluluk: Ekip kendi süreciyle karşılar (devredilecek bir taraf yok).
3. Varlıklara bağlama: Doğrudan bir "varlığa" değil, geliştirme sürecine bağlanır; S5'te değil, kılavuzun "geliştirme yaşam döngüsü" bölümünde belgelenir.
4. Tehditlere bağlama: Tehdit: "kötü niyetli ya da hatalı bir değişikliğin fark edilmeden ana dala girmesi" (6. hafta tedarik zinciri güvenliği).
5. Önlem ve doğrulama: Önlem: birleştirme isteği (pull request) kuralı, en az bir onay zorunlu. Doğrulama: sürüm kontrol geçmişinde son 20 birleştirmenin en az bir onay kaydına sahip olduğu kontrol edilir.
6. Sürüm planı: Bu süreç zaten yürürlükte; "karşılandı", sürekli izlenmesi gereken bir kural olarak not düşülür (bir kerelik değil, her birleştirmede geçerli).

Bu ikinci örnek, altı adımın yalnız "kripto gereksinimleri" için değil, her gereksinim türü (işlevsel, güvence, süreç) için aynı şekilde çalıştığını gösterir.

Sürüm planına işlemek: küçük bir örnek¶

Altıncı adımın ("hangi gereksinimin hangi sürümde karşılanacağı") somut bir proje planı satırına dönüşmüş hâli:

Bu tablo, S17'deki (uyum matrisi) "karşılanmadı" satırlarının proje yönetimi tarafındaki karşılığıdır; S17'yi güncelleyen kişi, aynı oturumda bu tabloyu da güncellemelidir — aksi hâlde iki belge birbirinden ayrışır ve biri diğerini yalanlar.

Neden bu altı adımı atlamak cazip ama yanlıştır¶

Bir gereksinim listesini okuyup doğrudan "hepsi karşılanıyor" demek, altı adımı atlamanın en hızlı yoludur — ve tam olarak bu yüzden en sık yapılan hatadır. Zaman baskısı altındaki takımlar üçüncü adımı (varlıklara bağlama) ve dördüncü adımı (tehditlere bağlama) atlar çünkü bunlar "yazı işi" gibi görünür. Ama bu iki adım atlandığında, geriye kalan "karşılandı" iddiası hiçbir şeye dayanmaz; 9. bölümdeki proje kontrol listesi bu yüzden S5 (varlık tablosu) ile S17'yi (uyum matrisi) birlikte gözden geçirmeyi ister.

8. Dersin gereksinim aileleri¶

Dönem projeniz için, açık standartlardan (ETSI EN 303 645, OWASP MASVS, NIST SSDF, Ortak Kriterler katalogları) ve sektör belgelerinin yapısından uyarlanmış bir gereksinim seti kullanıyoruz. Kimlikler CEN429-<aile>-<numara> biçimindedir.

İşlenmiş örnek: bir uyum matrisi satırını baştan sona, hatalarıyla birlikte doldurmak¶

Bir takımın CEN429-AP-04 ("uygulama çalışma anında kendi bütünlüğünü denetlemelidir") için matris satırını nasıl doldurduğunu, ilk taslaktan düzeltilmiş hâline kadar izleyelim; bu, 1. bölümdeki "kötüden iyiye" fikrinin bir uyum matrisi satırına uygulanmış hâlidir.

İlk taslak (yetersiz):

Bu satırın üç sorunu var: (1) "Bütünlük kontrolü var" bir önlem açıklaması değil, gereksinimin tekrarı; hangi mekanizma (checksum mı, imza doğrulama mı, hata ayıklayıcı algılama mı) belirtilmiyor. (2) "Test edildi" doğrulama yöntemi değil, doğrulamanın var olduğunun iddiası. (3) Kanıt sütunu boş.

Düzeltme adım adım:

1. Ekip önlemi somutlaştırır: uygulama açılışta kendi kod bölümünün bir özetini (hash) hesaplar ve derleme zamanında gömülen beklenen özetle karşılaştırır; uyuşmazsa çalışmayı durdurur. Bu, kılavuzun S12.3 bölümünde anlatılır.
2. Doğrulama yöntemi netleştirilir: bir test aracı, ikili dosyanın (binary) bir baytını değiştirip uygulamanın başlamayı reddettiğini doğrular.
3. Kanıt eklenir: bu testin CI'da otomatik çalıştığı iş (ci-integrity-check), son çalıştırma kaydı ve çıktı günlüğü.

Düzeltilmiş satır:

Fark, satırın uzunluğunda değil, her hücrenin somutluğundadır. İlk taslak da "dolu" görünüyordu; ama hiçbir hücresi bağımsız olarak doğrulanamazdı.

Ailelerin arkasındaki mantık: neden dokuz aile?¶

Sekiz aile (AP, ID, AS, DR, DU, DT, RP, CR) artı süreç ailesi (DV), sektördeki gerçek kılavuzlarda tekrar eden dokuz soruya karşılık gelir: "Uygulama kendini nasıl koruyor (AP)? Kime güveniyor (ID)? Neyi koruyor (AS)? O korunan şey nerede duruyor — diskte (DR), bellekte (DU) yoksa ağda mı (DT)? Bir şeyler ters giderse ne söylüyor/söylemiyor (RP)? Bunların hepsini hangi kriptografik araçlarla yapıyor (CR)? Ve bunu üreten ekip nasıl çalışıyor (DV)?" Bu dokuz soru, EMVCo'nun yazılım tabanlı mobil ödeme belgesindeki bölüm başlıklarıyla neredeyse birebir örtüşür (6. bölümde görüldüğü gibi) çünkü sektördeki neredeyse her güvenlik kılavuzu aynı dokuz soruyu farklı sırayla sorar.

Aile seçerken sık yapılan bir hata: yanlış aileye yazmak¶

Bir gereksinimi yanlış aileye koymak (ör. "anahtar iş bitince silinmelidir" gereksinimini CR yerine DU'ya yazmak) büyük bir hata değildir ama tutarlılığı bozar: aynı türden gereksinimleri ararken değerlendirici belirli bir aileye bakar; gereksinim yanlış ailede duruyorsa gözden kaçabilir.

AS ailesi ile DR/DU/DT aileleri arasındaki fark¶

Yeni başlayanlar sık sık "AS (varlık koruması) ile DR (beklemede veri) aynı şey değil mi?" diye sorar. Fark şudur: AS, varlığın kendisiyle ilgilidir (hangi varlık var, nasıl sınıflandırılmış, kopyası ele geçirilirse ne olur); DR/DU/DT ise aynı varlığın hangi durumda (beklemede/kullanımda/aktarımda) olduğuyla ilgilidir. Aynı varlık (ör. bir kripto anahtarı) hem bir AS gereksiniminin (ör. "her anahtar için konum ve yaşam döngüsü tanımlanmalı") hem bir DU gereksiniminin (ör. "oturum verisi işlemden hemen sonra bellekten silinmelidir") konusu olabilir — biri varlığın envanterini, diğeri varlığın belirli bir andaki durumunu sorar.

Dokuz aileyi tek bakışta hatırlamak¶

AP-ID-AS-DR-DU-DT-RP-CR-DV sırası akılda tutulması zor olabilir; şu soru zincirini hatırlamak yardımcı olabilir: "Kendini koruyor mu (AP)? Kime güveniyor (ID)? Neyi koruyor (AS)? O şey nerede — beklemede (DR), kullanımda (DU), aktarımda (DT)? Sorun olursa ne diyor (RP)? Hangi araçla (CR)? Kim üretti, nasıl (DV)?" Bu, 1. haftadan beri takip ettiğimiz "varlık → tehdit → önlem" zincirinin dokuz parçaya bölünmüş hâlidir.

9. Dönem projesi: bu hafta¶

• S17 — Uyum matrisi: dersin gereksinim ailelerinden projenize uygulananların tamamı; her satırda durum, bölüm, doğrulama ve kanıt.
• S14 — Varsayımlar ve devredilen gereksinimler: desteklenen platformlar, kapsam dışı bileşenler, kullanıcı ve ortam varsayımları; devredilen her gereksinim için kime, neden ve nasıl.
• S1 — Kaynaklar: hangi standartlara dayandığınızı (ETSI EN 303 645, OWASP MASVS, NIST SSDF, CERT) belirtin.
• Varlık tablonuzu (S5) gereksinimlere göre gözden geçirin: her varlığın yaşam döngüsü ve koruma sınıfı dolu mu?

Bu haftaki teslimi 45 dakikada hazırlamanın yolu¶

S17 ve S14, değerlendiricinin ilk açtığı belgelerdir (bu haftanın başındaki bilgi kutusunda da belirtildiği gibi); bu yüzden dağınık bırakmak, projenin geri kalanı iyi olsa bile kötü bir ilk izlenim yaratır. Önerilen sıra:

1. 8. bölümdeki aile tablosundan projenize uygulanan gereksinimleri işaretleyin (kopyala-yapıştır, sonra uygulanmayanları silmek yerine "uygulanmaz, gerekçe: ..." olarak bırakın — 7. bölümdeki kural).
2. Her biri için 2. bölümdeki altı sütunu (kimlik, gereksinim, durum, önlem, doğrulama, kanıt) doldurun; kanıt sütununu doldurmadan "karşılandı" yazmayın.
3. "Devredildi" işaretlediğiniz her satırı S14'e taşıyın; kime/neden/nasıl üçlüsünü 3. bölümdeki örnek gibi tam cümlelerle yazın.
4. Varlık tablonuzu (S5) açın; her gereksinimin bağlandığı varlığın satırını bulun. Bağlanamıyorsa ya varlık eksiktir ya da gereksinim bu ürüne uygulanmaz.
5. S1'e (kaynaklar) hangi standartlara dayandığınızı yazın — 6. bölümdeki "standartları nasıl seçersiniz" rehberine bakın.

Kanıt klasörünüzü nasıl düzenlemelisiniz¶

Uyum matrisindeki her kanıt referansının gerçekten bulunabilir olması için basit bir klasör düzeni önerilir:

evidence/
  week13/
    test_butunluk_ci482.log
    mitm_test_2026-11-03.log
    handshake.pcapng
    integrity_test.log
  README.md   <- her dosyanın hangi gereksinimin kanıtı olduğunu bir satırla listeler

README.md dosyası, uyum matrisindeki kanıt sütununun aynasıdır: matriste "kanıt: X dosyası" yazan her satır, bu klasörde gerçekten bulunabilmelidir. Klasör boşsa ya da dosya eksikse, matris kanıtsız sayılır — tıpkı 2. bölümdeki kuralda anlatıldığı gibi.

Zamanınız yetmiyorsa: öncelik sırası¶

Bu hafta teslim edilecek çok şey var; zaman kısıtlıysa şu sırayla ilerleyin (en çok puanı en az zamanla kazandıran sıra):

1. Önce en az 15 gereksinimlik bir S17 iskeleti çıkarın (kimlik + gereksinim + durum sütunları dolu, önlem/ doğrulama/kanıt boş olabilir) — boş bir S17'den çok daha iyidir.
2. Sonra "karşılandı" dediğiniz satırlardan kanıtı gerçekten elinizde olanları tamamlayın; kanıtı olmayanları dürüstçe "karşılanmadı" yapın.
3. Sonra devredilen satırları S14'e taşıyın.
4. Son olarak kalan satırların önlem/doğrulama sütunlarını doldurun.

Bu sıra, "az ama dürüst" bir matrisin "çok ama kanıtsız" bir matristen her zaman daha iyi puan aldığı ilkesine dayanır (bkz. 2. ve 8. bölümlerdeki kanıt kuralları).

Bu hafta neden acele etmemelisiniz¶

S17 ve S14, dönem projesinin yalnızca son haftasına değil, her hafta biraz büyüyen bir belgeye dönüşmelidir. Dönem boyunca her yeni önlem eklediğinizde ("bu haftaki proje adımı" bölümlerinde), o önlemin hangi gereksinimi karşıladığını da not ederseniz, bu haftaya geldiğinizde S17 zaten yarı dolu olur. Bu haftanın gerçek işi, o zaman yalnızca eksik satırları tamamlamak ve tutarlılığı kontrol etmek olur.

10. Kendi başına çalış¶

Bu alıştırmaları neden kendi başınıza çözmelisiniz¶

Yukarıdaki bölümlerde gördüğünüz işlenmiş örnekler (kötü→iyi gereksinim, uçtan uca izlenebilirlik zinciri, ST iskeleti, FIPS denetimi, standartlar arası eşleme, uyum matrisi satırı) hepsi başka gereksinimler ve başka varlıklar üzerinden anlatıldı. Amaç, yöntemi göstermekti; şimdi aynı yöntemi kendi projenizin varlıklarına ve gereksinimlerine uygulamanız gerekiyor. Bir yöntemi yalnız izleyerek değil, bir kez de kendi başınıza uygulayarak öğrenirsiniz — özellikle Alıştırma 1 ve 3'te, hangi kelimenin belirsiz olduğunu siz fark etmelisiniz; bu beceri ancak pratikle gelir.

Kendi cevabınızı değerlendirmek için bir mini kontrol listesi¶

Her alıştırmayı bitirdikten sonra şu beşliyi kontrol edin (2. bölümdeki "değerlendiricinin sık yazdığı beş bulgu türü" listesinin ters çevrilmiş hâlidir):

• Cevabımda kanıtsız bir "karşılandı" var mı?
• Kimlikler tutarlı mı (aynı gereksinime her yerde aynı kimlik)?
• Yazdığım her önlem bir gereksinime bağlı mı?
• "Uygulanmaz" dediğim yerlerde gerekçe var mı?
• Kanıt olarak genel bir cümle mi, yoksa somut bir referans mı yazdım?

Bu beş maddenin hepsine "hayır" (yani sorun yok) diyebiliyorsanız, cevabınız değerlendirici standardına yakındır.

Alıştırma 1 için başlangıç şablonu¶

Hâlâ nereden başlayacağınızı bilmiyorsanız, şu boşluk doldurma şablonunu kullanın (1. bölümdeki altı adımın sıkıştırılmış hâli):

"[Hangi varlık], [hangi tehdide karşı], [hangi hedefle: gizlilik/bütünlük/kullanılabilirlik], [hangi araç sınıfıyla], [hangi durumda: beklemede/kullanımda/aktarımda], [MUST/SHOULD] korunmalıdır."

Her köşeli parantezi doldurduğunuzda, elinizde 1. bölümdeki örneklere benzer bir gereksinim olur. Boşluklardan biri doldurulamıyorsa (ör. "hangi tehdide karşı" sorusuna cevap veremiyorsanız), bu, gereksinimin henüz olgun olmadığının bir işaretidir — tehdit modelinize geri dönün (1. hafta).

11. Kendini sınama¶

12. Kaynaklar ve ileri okuma¶

Ders kitabı — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003: Tarif 11.18 (istatistiksel rastgelelik testleri ve FIPS 140 bağlamı; bugün FIPS 140-3 ve NIST SP 800-90B/22).

Açık standartlar ve kaynaklar

• ISO/IEC 15408 (Ortak Kriterler) ve ISO/IEC 18045 (CEM); commoncriteriaportal.org'daki koruma profilleri.
• FIPS 140-3, ISO/IEC 19790 ve 24759; NIST SP 800-140 serisi; CMVP ve CAVP.
• ETSI EN 303 645 ve ETSI TS 103 701 (uygunluk değerlendirmesi).
• GSMA IoT Security Guidelines; GSMA SAS.
• EMVCo yazılım tabanlı mobil ödeme belgeleri (genel yapı); PCI MPoC, PCI DSS v4.0, PCI Secure Software Framework.
• OWASP MASVS ve MASTG; NIST SP 800-218 (SSDF).
• RFC 2119 / RFC 8174 (zorunluluk sözcükleri).

Bu kaynakları neden böyle seçtik¶

Bu haftanın kaynak listesi kasıtlı olarak açık ve ücretsiz erişilebilir standartlardan oluşur (kart şemalarının kendi metinleri hariç, çünkü onlar gizlilik anlaşmasıyla paylaşılır — bkz. sayfa başındaki bilgi kutusu). Amaç, bu dersten sonra da erişebileceğiniz, projenizde doğrudan referans verebileceğiniz kaynaklar sunmaktır; sınavda ya da projede "standart X şöyle diyor" dediğinizde, o standardın gerçekten erişilebilir olduğundan emin olmak istiyoruz.

Kaynakları S1'de nasıl biçimlendirirsiniz (örnek)¶

S1 — Kaynaklar (örnek biçim)
[1] ETSI EN 303 645 V2.1.1, "Cyber Security for Consumer Internet of Things: Baseline Requirements."
[2] ISO/IEC 15408-1:2022, Common Criteria for Information Technology Security Evaluation.
[3] OWASP Mobile Application Security Verification Standard (MASVS) v2.0.
[4] NIST FIPS 140-3 (2019), Security Requirements for Cryptographic Modules.

Her kaynağın sürüm/tarih bilgisiyle listelenmesi, bu bölümün başındaki kuralın doğrudan uygulamasıdır; aynı biçim, kılavuzunuzdaki gereksinim bloklarında (3. bölüm) standarda referans verirken de kullanılabilir.

Bu haftanın kısa özeti¶

Bu hafta bir gereksinimi sıfırdan iyi yazmayı (1. bölüm), onu kanıta kadar izlemeyi (2. bölüm), kılavuza doğru biçimde yazmayı (3. bölüm) ve büyük standart ailelerinin (Ortak Kriterler, FIPS 140-3, ETSI/GSMA/EMVCo/PCI/ MASVS) aynı ihtiyaçları nasıl farklı sözcüklerle ifade ettiğini (4-6. bölümler) gördük. 7-8. bölümlerde bunları projenize nasıl aktaracağınızı, 9. bölümde bu haftaki somut teslimi adım adım nasıl hazırlayacağınızı işledik. Dönem başından beri topladığınız varlık tablosu (1. hafta), koruma kuralları (9. hafta) ve değerlendirme süreci (geçen hafta) bilgileri, bu hafta tek bir belgede (uyum matrisi) birleşiyor — gelecek haftalarda bu belge, projenizin değerlendiriciye sunacağınız ilk ve en önemli sayfası olacak.