Ö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, varlıklar, tehditler, karşı önlemler, doğrulama, kalan risk; her varlığın nerede durduğu, ne zaman oluşup silindiği ve hangi korumayı (C/I) gerektirdiği bir varlık tablosunda listelenir (Hafta 1)
• 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ı yürüttüğü değerlendirme süreci; değerlendiricinin belgelediği her eksiklik bir bulgudur (Hafta 12)

Bu hafta: varlık tablosunu her gereksinime bağlıyoruz, bağımsız değerlendirme disiplinini "gereksinimden kanıta izlenebilirlik zinciri" olarak kullanıyoruz — çıktı, projenizin uyum matrisi (S17) ve devredilenler (S14).

Gereksinim (requirement) nedir?

• Gereksinim: sistemin karşılaması gereken bir koşul.
• Güvenlik gereksinimi: bir güvenlik koşulu.
• İyi gereksinim doğrulanabilir (test edilebilir).

İyi gereksinim ölçütleri — şema

Üç tür (hatırlatma)

İyi gereksinim ölçütleri

• Doğrulanabilir: test edilebilir mi?
• Tekil: tek bir şey mi söylüyor?
• Ölçülebilir: somut mu?
• Gerçekçi: uygulanabilir mi?

Kötü → iyi (1)

• Kötü: "Uygulama güvenli olmalıdır."
• İyi: "Sürüm derlemesi yığın koruyucu, PIE ve tam RELRO ile üretilmelidir."

Neden iyi? Test edilebilir (checksec).

Kötü → iyi gereksinim — şema

Kötü → iyi (2)

• Kötü: "Veriler şifrelenmelidir."
• İyi: "C sınıfı her varlık beklemede ≥128 bit düzeyinde AEAD ile şifrelenmelidir."

Neden iyi? Hangi veri, hangi düzey, hangi yöntem belli.

Kötü → iyi (3)

• Kötü: "Anahtarlar iyi yönetilmelidir."
• İyi: "(1) Her anahtarın amacı, kripto-periyodu ve imhası belgelenir. (2) İş bitince bellekten silinir."

Tekil, doğrulanabilir maddeler.

İşlenmiş örnek · kötü gereksinimi iyileştirmek

Başlangıç cümlesi (gerçek bir taslaktan):

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

Bu cümleyi altı adımda iyi bir gereksinime dönüştüreceğiz; her adımda önce/sonra ve neden değişti.

Adım 1 — Belirsiz kelimeleri işaretleyin

• Önce: "Uygulama, kullanıcı verilerini korumalıdır."
• Belirsiz kelimeler: "kullanıcı verileri" (hangi veri?), "korumalıdır" (neye karşı, hangi düzeyde?).
• Neden değişti: değerlendirici bu cümleyi okuyunca test edecek hiçbir şey bulamaz.

Adım 2 — Varlık tablosuna bağlayın

• Sonra: "Yerel veritabanındaki C sınıfı alanlar korunmalıdır."
• Neden değişti: "kullanıcı verileri" tek şey değil; varlık tablosunda (1. hafta) ayrı satırlardır — oturum belirteci, profil, ödeme jetonu... her biri farklı sınıfta.
• Hâlâ "korunmalı" ölçülemez → sıradaki adım.

Adım 3 — Koruma hedefini netleştirin

• Sonra: "...C sınıfı alanların gizliliği ve bütünlüğü korunmalıdır."
• Neden değişti: tehdit modeli hem "dosyayı okuma" (gizlilik) hem "dosyayı değiştirme" (bütünlük) riskini gösteriyor; ikisi de aynı anda gerekli.

Adım 4 — Ölçülebilir teknik kriter ekleyin

• Sonra: "...kimlik doğrulamalı şifrelemeyle (AEAD) korunmalıdır."
• Neden değişti: 9. hafta kuralı — gizlilik ve bütünlük aynı anda isteniyorsa doğru araç sınıfı AEAD'dir; hâlâ belirli bir kütüphane adı verilmiyor.

Adım 5 — Durum ve zorunluluk sözcüğünü ekleyin

• Sonra: "Beklemedeki C sınıfı hassas veri, kimlik doğrulamalı şifrelemeyle (AEAD) korunmalıdır." (MUST)
• Neden değişti: veri burada beklemede (disk üzerinde); "-malıdır" seçildi çünkü tehdide karşı vazgeçilmez bir koşul — "-abilir" olsaydı isteğe bağlı sayılırdı.

Adım 6 — Kimlik verin ve tehdide bağlayın

• Sonra (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".)
• Neden değişti: kimliksiz bir gereksinim izlenebilirlik zincirine hiç girmez.

Bir gereksinimin yaşamı (animasyon)

Bir gereksinimin yaşamı — uç durum: tek kelimelik belirsizlik

Gereksinim kalitesi denetleyicisi (animasyon)

Gereksinim kalitesi denetleyicisi — uç durum: tek cümle, tek kural

Zincir

Her gereksinim bu zincirle bir kanıta bağlanmalı.

İzlenebilirlik neden önemli?

• Değerlendirici "bu gereksinim nerede?" diye sorar.
• İzlenebilirlik yoksa: her şeyi baştan aramak.
• Varsa: matristen doğrudan bulunur.

İzlenebilirlik örneği

İki yön

• İleri: gereksinim → nerede karşılandı?
• Geri: bu kod/test → hangi gereksinimi karşılıyor?
• İyi matris iki yönde de izlenebilir.

⚠️ Kanıtsız "karşılandı"

• Matriste "karşılandı" ama kanıt yoksa...
• Değerlendirici gözünde karşılanmamış sayılır.
• İlk bulgulardan biri olur.

İşlenmiş örnek · uçtan uca zincir

Zincirin nasıl kurulduğunu tek bir varlık üzerinden başından sonuna dolduralım: kullanıcının oturum belirteci.

Altı halka: varlık → tehdit → gereksinim → önlem → doğrulama → kanıt.

1. Varlık

2. Tehdit

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

3. Gereksinim

Varlık → tehdit → hedef (gizlilik+kimlik) → araç sınıfı → durum → zorunluluk zinciri kısaca tekrar uygulanır:

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ılavuzun S10.3 "Aktarım güvenliği" bölümü:

"İ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

Güvenlik testi ekibi bir MITM (ortadaki adam) aracıyla bağlantıya araya girmeye çalışır:

• Geçersiz/kendinden imzalı sertifika sunulunca bağlantının reddedildiğini doğrular.
• Düz metin (TLS'siz) bağlantı denemesinin reddedildiğini doğrular.

6. Kanıt

• Test aracının günlük çıktısı: mitm_test_2026-11-03.log
• CI çalıştırma kaydı: #617
• TLS handshake paket dökümü: handshake.pcapng
• evidence/week13/ klasöründe saklanır, matriste bu dosya adlarıyla referans verilir.

İzlenebilirlik zinciri (animasyon)

İzlenebilirlik zinciri — uç durum: her satır boşluklu

Bölüm 2'nin kuralı

• Her "karşılandı" satırının kanıt sütununda bulunabilir, adlandırılmış bir referans olmalı: dosya adı, CI numarası, test raporu bölümü.
• "Var", "test edildi" kanıt değil, kanıt vaadidir.
• Değerlendiricinin en sık yazdığı bulgu: kanıtsız "karşılandı".

Bölüm 1–2 — kısa sınama

1. İyi gereksinimin dört ölçütü?
2. "Uygulama güvenli olmalı" neden kötü?
3. İzlenebilirlik zinciri nedir?

Bölüm 1–2 — cevaplar

1. Belirli · ölçülebilir/doğrulanabilir · tekil · izlenebilir (gerçekçi, atomik).
2. Belirsiz ve ölçülemez; "güvenli"nin tanımı yok → test edilemez, herkes farklı anlar.
3. Tehdit/standart → gereksinim → tasarım/kod → test/kanıt. Her gereksinim bir kaynağa ve bir kanıta iki yönlü bağlanır.

Devretme üç soru — şema

Gereksinim bloğu kalıbı

Her gereksinim bir blok olarak yazılır:

• Kimlik: benzersiz numara (ör. CEN429-DU-01)
• Metin: ne isteniyor (tekil, ölçülebilir)
• Durum: karşılandı / devredildi / karşılanmadı
• Karşılama: nasıl karşılandı
• Doğrulama + kanıt

Örnek blok

CEN429-DU-01
Metin: Yerel DB'deki C sınıfı veri AEAD ile şifrelenir.
Durum: Karşılandı
Karşılama: AES-256-GCM, anahtar TEE'de
Doğrulama: T-05 birim testi
Kanıt: test çıktısı, S16

Neden blok?

• Her gereksinim aynı yapıda → karşılaştırılabilir.
• Değerlendirici hızlı okur.
• Uyum matrisi bu bloklardan üretilir.

Devredilen gereksinim nedir?

• Bir bileşen bir gereksinimi kendisi karşılayamıyor.
• Sorumluluğu üst uygulamaya/OS'a/donanıma devreder.
• Bu bir kaçış değil, açık bir sözleşmedir.

Devrederken üç soru

Devredilen her gereksinimde yaz:

• Kime? (üst uygulama / OS / donanım)
• Neden? (neden bu bileşen karşılayamıyor)
• Nasıl? (karşı taraf nasıl karşılayacak)

Devredilen · örnek

CEN429-AP-03: Güvenli kurulum ve güncelleme
Durum: Devredildi
Kime: Üst mobil uygulama (MPA)
Neden: SDK dağıtım kanalına sahip değil
Nasıl: MPA imzalı güncelleme + sürüm denetimi sağlar

⚠️ Sessiz devretme yok

• Bir gereksinimi karşılamıyor ve yazmıyorsanız → eksik.
• Devretme belgelenmeli; aksi halde "karşılanmadı" sayılır.
• S14 bölümü tam bunun için.

Karşılandı mı, devredildi mi?

İşlenmiş örnek · bloğu doldurmak (Karşılandı)

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 (S7.2); anahtar cihazın güvenli depolama biriminden türetilir. Doğrulama: birim testi, tek bayt değişince çözmenin reddedildiğini kontrol eder. Kanıt: CI #482, evidence/week13/test_butunluk_ci482.log.

Aynı kalıp · Devredildi

[CEN429-AP] CEN429-AP-07 — DEVREDİLDİ (üst uygulamaya)
Gereksinim: Uygulama güvenli biçimde kurulmalı ve güncellenmelidir.
Karşılama: Kütüphanenin kendi dağıtım/güncelleme mekanizması yok. Kime: üst uygulama geliştiricisi. Neden: kütüphane ağ/dosya sistemi seviyesinde kuruluma erişmez. Nasıl: mağaza imza doğrulaması ya da Hafta 6'daki imzalama şemasıyla imzalı güncelleme paketleri.

Devredilen blok da Karşılama alanına sahiptir — ama "karşı taraf nasıl yapmalı, biz neden yapmıyoruz" sorusunu cevaplar.

Aynı kalıp · Karşılanmadı

[CEN429-DT] CEN429-DT-04 — KARŞILANMADI
Gereksinim: Sunucu sertifikası sabitlenmelidir (certificate pinning).
Durum: Şu an yalnız standart TLS zinciri doğrulaması var, sabitleme yok. Kalan risk: güvenilir bir kökten sahte sertifika alınırsa MITM mümkün olabilir (S16.4). Planlanan düzeltme: v1.1 (görev #217).

"Karşılanmadı" bloğu Karşılama yerine Durum ve Kalan risk alanlarını doldurur.

Blok alanlarının görevi

• 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/tehditten gelen "ne"yi tekrarlar, yeniden yorumlanmaz.
• Karşılama: "nasıl"ı somut dosya/bölüm adlarıyla anlatır.
• Doğrulama + Kanıt: izlenebilirlik zincirinin son iki halkası.

Gereksinim bloğu (animasyon)

Gereksinim bloğu — uç durum: sessiz devir

Bölüm 3 — kısa sınama

1. Gereksinim bloğunun alanları?
2. Devrederken hangi üç soru yanıtlanır?
3. Sessiz devretme neden sorun?

Bölüm 3 — cevaplar

1. ID · ölçülebilir ifade · kaynak/gerekçe · ilgili varlık/tehdit · doğrulama yöntemi (kanıt) · durum/öncelik.
2. (1) Neden şimdi karşılanmıyor? (2) Riski ne, kim kabul ediyor (onay)? (3) Ne zaman/nasıl karşılanacak (plan/telafi)?
3. Kayıt/onay olmadan gereksinim atlanır → gizli açık, sorumlusu yok, denetimde patlar. Açık, gerekçeli, onaylı devret.

Ortak Kriterler — şema

CC nedir?

• Ortak Kriterler: ürün güvenliğini değerlendirmenin uluslararası standardı.
• Ortak bir dil ve yöntem sağlar.
• Ülkeler birbirinin değerlendirmesini tanır.

TOE · değerlendirme hedefi

• TOE (Target of Evaluation): değerlendirilen tam ürün.
• Benzersiz tanımlanır (12. hafta): sürüm + binary + özet.
• Kapsam dışı bileşenler yazılır.

ST · güvenlik hedefi

• ST (Security Target): bu ürünün güvenlik hedefi belgesi.
• İçinde: tehditler, amaçlar, gereksinimler (SFR/SAR).
• Ürüne özgüdür.

PP · koruma profili

• PP (Protection Profile): bir ürün sınıfı için ortak gereksinim seti.
• Örnek: "mobil cihaz PP", "akıllı kart PP".
• ST'ler genelde bir PP'yi temel alır.

ST vs PP

SFR · işlevsel gereksinimler

• SFR (Security Functional Requirements): ürünün ne yapacağı.
• Örnek: şifreleme, erişim denetimi, günlükleme.
• Standart bir katalogdan seçilir.

SAR · güvence gereksinimleri

• SAR (Security Assurance Requirements): doğru yapıldığına nasıl güveneceğiz.
• Örnek: kaynak inceleme, test derinliği, zafiyet analizi.
• EAL bunları belirler.

EAL · değerlendirme derinliği

• EAL (Evaluation Assurance Level): 1'den 7'ye derinlik.
• Yüksek EAL = daha derin inceleme.
• "+" ek güvence bileşenlerini gösterir (EAL4+).

⚠️ EAL yanlış anlaşılması

• EAL güvenliğin derinliği, güvenliğin miktarı değil.
• "EAL4+ > EAL2 daha güvenli" demek yanlış.
• Güvenlik, ST'deki tehdit ve amaçlara bağlıdır.

İşlenmiş örnek · ST iskeleti — TOE

Bir mobil ödeme bileşeni için üç adımda dolduralım.

Adım 1 — TOE'yi tanımlayın:

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

Kapsam dışını yazmak, kapsamı yazmak kadar önemlidir.

EAL merdiveni (animasyon)

EAL merdiveni — uç durum: EAL7, merdivenin tamamı

FIPS 140-3 düzeyleri — şema

FIPS 140-3 nedir?

• Kriptografik modüllerin doğrulanması standardı.
• Modülün algoritmaları, kendini testi, anahtar yönetimi.
• Yalnız modülü kapsar.

Güvenlik düzeyleri (1–4)

FIPS 140-3 düzeyleri (animasyon)

FIPS 140-3 düzeyleri — uç durum: Düzey 4

⚠️ FIPS uyumluluğu tuzağı

• FIPS doğrulanmış kütüphane kullanmak, uygulamayı otomatik FIPS uyumlu yapmaz.
• Uygulama modülü onaylı kipte ve doğru kullanmalı.
• Anahtarları da doğru yönetmeli.

CC ve FIPS birlikte

• CC: ürünün bütününü değerlendirir.
• FIPS: kripto modülünü doğrular.
• Bir ürün CC değerlendirmesinde FIPS'li modül kullanabilir.

İşlenmiş örnek · FIPS düzey 1 denetimi

Proje kripto katmanı: OpenSSL EVP arayüzü, AES-256-GCM, anahtarlar getrandom()'dan üretiliyor, hata durumunda sessizce varsayılan bir anahtara düşüyor.

Düzey 1 beklentilerini tek tek işaretleyelim.

Bölüm 4–5 — kısa sınama

1. ST ile PP farkı?
2. SFR ve SAR nedir?
3. "EAL4+ her zaman daha güvenli" neden yanlış?
4. FIPS'li kütüphane uygulamayı FIPS uyumlu yapar mı?

Bölüm 4–5 — cevaplar

1. PP bir ürün sınıfı için standart gereksinim kümesi; ST belirli bir ürünün (TOE) neyi karşıladığını söyleyen belge.
2. SFR ürünün ne yapacağı (fonksiyonel); SAR buna ne kadar güvenileceği (güvence; EAL buradan gelir).
3. EAL güvence derinliğini ölçer, güvenlik miktarını değil; kapsam (ST/TOE) darsa yüksek EAL az şey kapsar.
4. Hayır. Modülü doğru kip/yapılandırmada, onaylı algoritmalarla kullanmak gerekir. Modül sertifikası ≠ uygulama uyumu.

Sektör standartları — şema

Neden sektör standartları?

• CC/FIPS geneldir; sektörler kendi risklerine göre ek gereksinim ister.
• IoT, mobil, ödeme farklı tehdit ortamları.
• Projeniz hangisine yakınsa onu izleyin.

ETSI EN 303 645 (IoT)

• Tüketici IoT için temel güvenlik gereksinimleri.
• Örnek: varsayılan parola yok, güvenli güncelleme, hassas parametreleri güvenle sakla.
• Geniş, uygulanabilir taban.

ETSI · örnek maddeler

• Benzersiz parolalar (ortak varsayılan yok).
• Güvenlik güncellemelerini yönet.
• Hassas güvenlik parametrelerini güvenle sakla (→ projede S5/S7/S8).

GSMA

• Mobil operatör ekosistemi için güvenlik yönergeleri.
• Cihaz, ağ, servis güvenliği.
• SIM/eSIM, kimlik.

EMVCo

• Kart ödeme ekosistemi standartları (kartlar, terminaller, mobil ödeme).
• İşlevsel uygunluk + güvenlik değerlendirmesi.
• Saldırı potansiyeli puanlaması (12. hafta).

PCI

• PCI DSS: kart verisi işleyen sistemler için güvenlik.
• PCI MPoC/CPoC: yazılım tabanlı ödeme kabulü.
• Sıkı; laboratuvar değerlendirmesi.

OWASP MASVS

• Mobile Application Security Verification Standard.
• Mobil uygulama güvenlik gereksinimleri.
• Düzeyler: temel (L1), derinlemesine (L2), direnç (R).

MASVS · projeniz için

• En uygulanabilir gereksinim seti.
• MASTG ile test edilir (12. hafta).
• Kripto, depolama, iletişim, kod kalitesi, direnç.

Karşılaştırma · ders

• Hepsi aynı kökü paylaşır: yazılı, doğrulanabilir gereksinim.
• Fark: kapsam ve sıkılık.
• Projeniz için MASVS en pratik başlangıç.

Sektör standartlarının ders ailelerine eşlenmesi (animasyon)

Sektör eşlemesi — uç durum: GSMA karşılığı olmayan aile

Bölüm 6 — kısa sınama

1. ETSI EN 303 645 kimin için?
2. MASVS neden projeniz için en uygun?
3. CC ile MASVS farkı?

Bölüm 6 — cevaplar

1. Tüketici IoT cihazları için temel güvenlik (varsayılan parola yok, güncelleme, güvenli iletişim…).
2. Proje uygulama odaklı; MASVS somut, kontrol edilebilir maddeler + MASTG test rehberi → doğrudan uygulanır.
3. CC ağır, akredite laboratuvar/sertifika (EAL); MASVS hafif, açık, geliştirici-dostu öz-değerlendirme standardı.

Uyum matrisinin yapısı — şema

Gereksinim aktarma kararı — şema

Gereksinim → varlık → önlem

Her gereksinim bir varlığa ve bir önleme bağlanır.

Varlık yönetimiyle bağ

• Gereksinimler S5 varlık listesine bağlanır.
• Her varlık: C/I/I+ etiketi, koruma önlemi.
• Gereksinim, o korumayı zorunlu kılar.

Plana aktarmak

• İşlevsel gereksinim → tasarım/kod (S6–S11).
• Güvence gereksinimi → test (S16).
• Süreç gereksinimi → geliştirme süreci (S13).

İşlenmiş örnek · CR-03'e altı adımı uygulamak

CEN429-CR-03 ("anahtarlar iş bitince silinmelidir"):

• 1. Uygulanabilirlik: oturum ve kasa dosyası anahtarı var → uygulanır.
• 2. Sorumluluk: kod projenin kendisi → biz karşılarız.
• 3. Varlıklara bağlama: kasa dosyası anahtarının "silinme" sütunu boş — eksiklik burada fark edilir.

Aynı örnek · tehditten sürüm planına

• 4. Tehditlere bağlama: "fiziksel erişimi olan saldırgan bellek dökümü alır" tehdidine bağlanır.
• 5. Önlem/doğrulama: crypto_wipe() çağrısı; doğrulama: bellek dökümünde anahtar baytlarının bulunmadığını göstermek.
• 6. Sürüm planı: oturum anahtarı v0.9'da karşılandı; kasa dosyası anahtarı v1.0'a planlandı, o güne kadar karşılanmadı + kalan risk yazılır.

Gereksinimi plana aktarmak (animasyon)

Gereksinimi plana aktarmak — uç durum: uygulanmaz

Gereksinim aileleri — şema

Dersin kendi kimlikleri

Bu ders, açık standartlardan uyarlanmış kendi gereksinim ailelerini kullanır:

CEN429-AP (uygulama koruma), ID (kimlik), AS (varlık), DR/DU/DT (veri: beklemede/kullanımda/aktarımda)…

Aileler (1)

Aileler (2)

Her aile → haftalara bağ

• AP → 4, 5, 6, 9, 11, 14
• CR/DR/DU/DT → 3, 10
• AS → 1, 3
• DV/RP → 12, 13

Projeniz bu ailelerden bir alt küme seçer.

Uyum matrisi etkinliği · Adım 1

• Kendi projenizden beş gereksinim seçin (farklı ailelerden).
• Her biri için bir gereksinim bloğu yazın.

Etkinlik · adım 2

Her gereksinim için matris satırı doldurun:

Etkinlik · adım 3

• En az birini devredilen olarak yazın (kime/neden/nasıl).
• En az birinin kanıtını somut gösterin.
• Bir "karşılanmadı" varsa kalan riske yazın.

Etkinlik · değerlendirme

Değerlendirici gözüyle kontrol:

• Her satırın kanıtı var mı?
• Devredilenler açık mı?
• Gereksinimler doğrulanabilir mi?

Taslağı düzeltme · adım adım

1. Önlemi somutlaştır: açılışta kod bölümünün özeti (hash) hesaplanır, derleme zamanında gömülü beklenen özetle karşılaştırılır; uyuşmazsa çalışma durur (S12.3).
2. Doğrulama yöntemini netleştir: binary dosyanın bir baytı değiştirilir, uygulamanın başlamayı reddettiği doğrulanır.
3. Kanıt ekle: CI işi ci-integrity-check, çalıştırma #391, integrity_test.log.

Fark neyde?

• Fark satırın uzunluğunda değil, her hücrenin somutluğunda.
• İlk taslak da "dolu" görünüyordu ama hiçbir hücresi bağımsız olarak doğrulanamazdı.
• Değerlendirici için önemli olan: her hücreyi okuyunca "bunu nereden biliyoruz?" sorusuna cevap bulabilmek.

Bölüm 8'in kuralı

• Her satırın kanıtı o satıra özgü olmalı: belirli test adı, belirli CI numarası, belirli günlük dosyası.
• Tek bir genel raporu bütün satırlara kopyalamak, matrisin tamamını şüpheli hâle getirir.
• Genel bir rapora referans veriliyorsa, raporun hangi bölümü/sayfası olduğu da belirtilmeli.

Bölüm 7–8 — kısa sınama

1. Gereksinim hangi iki şeye bağlanır?
2. Dersin gereksinim ailelerinden üçünü sayın.
3. Uyum matrisinde her satırda ne olmalı?

Bölüm 7–8 — cevaplar

1. Yukarıda kaynağa (tehdit/standart/varlık) ve aşağıda kanıta (test/kod) — iki yön.
2. (Dokuz aileden herhangi üçü) ör. veri güvenliği · kod sağlamlaştırma (hardening) · RASP · kriptografi/sertifika · bellek koruması · arayüz koruması.
3. Gereksinim ID+ifade · durum (karşılandı/devredildi) · kanıt (test/dosya/S-bölümü). Kanıtsız satır karşılanmamış sayılır.

Matristen okunanlar

• Üç karşılandı (kanıtlı), bir devredildi, bir kalan risk.
• Her satır izlenebilir.
• Değerlendirici bu tablodan başlar.

Proje · S14 ve S17

S17 ve S14, değerlendiricinin ilk açtığı belgelerdir.

• [ ] S17 uyum matrisi: uygulanan her gereksinim için durum, bölüm, doğrulama, kanıt.
• [ ] S14 devredilenler: kime, neden, nasıl.
• [ ] En az bir "karşılanmadı" varsa kalan riske yaz.

Değerlendirici gözüyle

• Kanıtsız "karşılandı" = karşılanmamış.
• Devredilenler açık ve gerekçeli mi?
• Gereksinimler doğrulanabilir mi?

Soru 1

İyi bir güvenlik gereksiniminin dört ölçütü?

Cevap: Doğrulanabilir, tekil, ölçülebilir, gerçekçi.

Soru 2

"Uygulama güvenli olmalıdır" neden kötü? Nasıl düzeltilir?

Cevap: Doğrulanamaz. Ölçülebilir yazılır: ör. "sürüm derlemesi yığın koruyucu, PIE ve tam RELRO ile üretilir".

Soru 3

İzlenebilirlik zinciri nedir?

Cevap: Gereksinim → önlem → doğrulama → kanıt. Her gereksinim bir kanıta bağlanır.

Soru 4

Uyum matrisinde kanıtsız "karşılandı" ne demek?

Cevap: Değerlendirici için karşılanmamış sayılır; ilk bulgulardan biridir.

Soru 5

Bir gereksinimi devrederken hangi üç soru yanıtlanır?

Cevap: Kime, neden, nasıl. Sessiz devretme "karşılanmadı" sayılır.

Soru 6

ST ile PP farkı?

Cevap: ST tek ürünün güvenlik hedefi; PP bir ürün sınıfı için ortak gereksinim seti. ST genelde bir PP'yi temel alır.

Soru 7

"EAL4+ her zaman EAL2'den güvenli" doğru mu?

Cevap: Hayır. EAL değerlendirmenin derinliğidir; güvenlik ST'deki tehdit ve amaçlara bağlıdır. "+" ek güvence bileşenidir.

Soru 8

FIPS doğrulanmış kütüphane kullanan uygulama FIPS uyumlu mudur?

Cevap: Tek başına değil. Doğrulama modülü kapsar; uygulama onaylı kipte, doğru kullanmalı, anahtarları doğru yönetmeli.

Soru 9

ETSI EN 303 645'in "hassas parametreleri güvenle sakla" maddesi projede nereye karşılık gelir?

Cevap: S5 varlık listesi, S7 veri güvenliği/kabuk matrisi, S8 anahtar yaşam döngüsü.

Soru 10

Bir kütüphane "güvenli güncelleme" gereksinimini karşılayamıyorsa?

Cevap: Üst uygulamaya devreder ve kılavuzda kime/neden/nasıl karşılanacağını yazar.