Ek A temaları ve kontrol seçimi

Madde 6.1.3 kuruma bir görev verir: risk işleme için gereken kontrolleri belirlemek ve bunları Ek A ile karşılaştırmak. Ek A, standardın sonunda duran bir kontrol listesidir.

Referans niteliğindedir. Kontrolleri istediğin kaynaktan seçebilir ya da kendin tasarlayabilirsin. Ama seçimini Ek A ile karşılaştırıp gerekli bir kontrolü atlamadığını göstermelisin. 2013 sürümünde Ek A 114 kontrolü 14 başlık altında topluyordu.

2022 revizyonu listeyi 93 kontrole indirdi ve dört temada topladı: organizasyonel, insana yönelik, fiziksel, teknolojik. Sayı azaldı ama kapsam daralmadı. Benzer kontroller birleşti; bulut ve tehdit istihbaratı gibi yeni konular eklendi. Bu derste temaları, kontrol özniteliklerini ve seçimin belgesi olan Uygulanabilirlik Bildirgesi'ni çözümlü bir örnekle göreceksin.

Kontrollerin numarası temayı söyler. Numaraların 5'ten başlaması, ISO/IEC 27002'nin bölüm numaralarından gelir. Organizasyonel temada 37 kontrol durur, numaraları 5.1 ile 5.37 arasındadır.

Politikalar, roller, tedarikçi ilişkileri ve olay yönetimi buraya girer. İnsana yönelik temada 8 kontrol var (6.1-6.8). İşe alım taraması, farkındalık eğitimi ve disiplin süreci bu temadadır.

Fiziksel temada 14 kontrol bulunur (7.1-7.14): giriş kontrolü, ekipman güvenliği, temiz masa kuralı gibi. Teknolojik temada 34 kontrol var (8.1-8.34). Erişim yönetimi, günlükleme, şifreleme ve güvenli kodlama bu temadadır. Dört temanın toplamı doksan üç eder ve her kontrol yalnız bir temaya girer.

2022 revizyonu on bir yeni kontrol ekledi. Bunları bilmek, eski bir BGYS'yi güncellerken nereye bakacağını gösterir. Organizasyonel temada üç yeni kontrol var: tehdit istihbaratı (5.7), bulut hizmetlerinin kullanımı için bilgi güvenliği (5.23) ve iş sürekliliği için BİT hazırlığı (5.30). Fiziksel temada bir tane var: fiziksel güvenlik izleme (7.4).

Teknolojik temada yedi yeni kontrol bulunur. Bunlar konfigürasyon yönetimi (8.9), bilgi silme (8.10), veri maskeleme (8.11), veri sızıntısı önleme (8.12), izleme faaliyetleri (8.16), web filtreleme (8.23) ve güvenli kodlamadır (8.28). Listeye dikkatli bak. Çoğu, son yılların olaylarından çıkan derslerdir: bulutta yanlış yapılandırma, sızan veri ve güvensiz kod.

Kurum Ek A'daki 93 kontrolün hepsini uygulamak zorunda değildir. Risk değerlendirmesi hangi kontrolün gerekli olduğunu belirler. Seçilen ve dışarıda kalan her kontrol, Uygulanabilirlik Bildirgesi (Statement of Applicability, SoA) adlı belgede yazılır.

6.1.3 d) bu belgede dört şey ister: gerekli kontroller, her birinin neden seçildiği, uygulanıp uygulanmadığı ve dışarıda kalan Ek A kontrollerinin gerekçesi. Uygulamada ekipler buna kontrol sahibini ve kanıtın yerini de ekler. Denetçi önce bu belgeye bakar ve risk kararlarıyla kontrol seçimini karşılaştırır.

Bir kontrolü gerekçesiz elemek denetimde kırmızı bayrak kaldırır. Bildirge yalnız denetim için yazılmaz. Yeni bir çalışan, hangi kontrolün neden seçildiğini buradan okur.

Seçimin iki kaynağı vardır. Birincisi risktir. Önceki modülde Altay Kargo, web sitesindeki SQL enjeksiyonu riskini azaltmayı seçmişti. Bu karar, güvenli kodlama kontrolünü Bildirge'ye 'uygulanıyor' diye yazdırır ve satır, risk kaydındaki kimliği taşır.

İkincisi yasal ya da sözleşmeden doğan yükümlülüktür. KVKK'nın 12. maddesi, veri sorumlusuna uygun güvenlik düzeyi için teknik ve idari tedbir alma yükü verir. Bu yükümlülük, risk puanı düşük çıksa bile bazı kontrolleri seçtirir.

Perakende zincirinin sözleşmesi de öyledir. Sözleşme yıllık sızma testi istiyorsa ilgili kontrol, risk puanından bağımsız seçilir. İzlenebilirlik budur. Her satır bir risk kimliğine ya da bir yükümlülüğe bağlanır.

Bildirge'yi hazırlarken sıralı bir yol izle. Önce risk kaydını aç ve 'azalt' kararı verilen her riski listele.

Her risk için riski düşürecek kontrolü yaz. Sonra yükümlülükleri ekle: KVKK, sözleşmeler ve sektör kuralları. Ardından listeni Ek A'nın 93 satırıyla karşılaştır. Karşılaştırma iki soru sorar.

Seçtiğin kontrol Ek A'da nereye düşüyor? Ek A'da olup senin listende olmayan bir kontrol gerçekten gereksiz mi? Dışarıda kalan her satıra gerekçe yaz. En son uygulanan her satıra bir sahip ve bir kanıt yeri ekle.

Belgeyi sürüm numarasıyla onaya sun. Altay Kargo'nun ilk taslağında on iki satır gerekçesizdi. Ekip bu satırları iç denetimden önce tek tek kapattı.

UYGULANABİLİRLİK BİLDİRGESİ - Altay Kargo (sürüm 1.2, dört satır)
5.23 Bulut hizmetlerinin kullanımı için bilgi güvenliği
     Durum: Uygulanıyor | Gerekçe: R-07 bulutta yanlış yapılandırma
     Kanıt: bulut politikası, sağlayıcı güvence raporu, yetki gözden geçirme kaydı
8.11 Veri maskeleme
     Durum: Kısmen | Gerekçe: R-03 test ortamında gerçek veri, KVKK md. 12
     Kanıt: maskeleme betiği (yalnız sipariş tablosu), kalan tablolar 2026-12
8.28 Güvenli kodlama
     Durum: Uygulanıyor | Gerekçe: R-01 web sitesinde SQL enjeksiyonu
     Kanıt: SAST raporu, birleştirme isteği (PR) kontrol listesi
8.30 Dış kaynak yoluyla geliştirme
     Durum: Uygulanmıyor | Gerekçe: kurum yazılım geliştirmeyi dışarıya vermiyor
     Kanıt: tedarikçi sicili (geliştirme hizmeti alınan firma yok)

Satırları tek tek oku. 5.23 uygulanıyor, çünkü Altay Kargo'nun sistemleri bulutta ve yanlış yapılandırma riski kayıtta. Kanıt sütunu sağlayıcının güvence raporunu da sayar. Bu rapor sağlayıcının payını kanıtlar ama kurumun sorumluluğunu bitirmez.

8.11 kısmen uygulanıyor. Standart yalnız 'uygulanıyor mu' diye sorar. 'Kısmen' ifadesi ekiplerin iş takibi için kullandığı bir ara durumdur ve bir bitiş tarihi taşımalıdır. 8.28'in gerekçesi doğrudan R-01'e bağlanır.

Kanıt olarak statik kod analizi (SAST) raporu ve kod inceleme listesi gösterilir. 8.30 uygulanmıyor ve gerekçesi somuttur: dışarıdan yazılım geliştirme hizmeti alınmıyor. Kanıt da bu gerekçeyi destekler. Tedarikçi sicilinde bir yazılım firması görünürse satır çöker.

Tema, bir kontrolün sahibini bulmayı kolaylaştırır. Teknolojik bir kontrolün sahibi çoğu zaman BT ekibidir.

Fiziksel bir kontrolün sahibi idari işler birimidir. Ama tema, kontrolün ne işe yaradığını söylemez. Bunun için ISO/IEC 27002:2022'ye bakarsın.

27002 her kontrole beş öznitelik ekler ve bunları etiketle yazar. Kontrol türü önleyici, tespit edici ya da düzelticidir. Bilgi güvenliği özelliği gizlilik, bütünlük ya da erişilebilirliktir.

Siber güvenlik kavramı Belirle, Koru, Tespit Et, Müdahale Et ya da Kurtar'dır. Bu beşli, NIST CSF'nin 1.1 sürümündeki fonksiyon adlarıyla aynıdır. Operasyonel yetenek, varlık yönetimi ya da uygulama güvenliği gibi bir iş alanıdır. Güvenlik alanı ise yönetişim ve ekosistem, koruma, savunma ya da dayanıklılıktır.

Öznitelikler sayesinde aynı listeye farklı bir gözlükle bakarsın. Bir kontrol her öznitelikte birden çok değer alabilir.

Altay Kargo'nun yönetim kurulu bir soru sordu: 'Bir sızıntıyı ne kadar hızlı fark ederiz?' GRC ekibi Bildirge'yi kontrol türüne göre süzdü ve yalnız tespit edici etiketli satırları çıkardı. Liste kısa kaldı. Kaydetme (8.15) ve izleme faaliyetleri (8.16) uygulanıyordu.

Fiziksel güvenlik izleme (7.4) ise yalnız ana depoda çalışıyordu. Bu görünüm, önleyici kontrollere çok, tespit edici kontrollere az yatırım yapıldığını gösterdi. Ekip yönetim kuruluna bu dengesizliği tek tabloyla anlattı. Aynı süzgeç erişilebilirlik ya da Kurtar etiketi için de çalışır.

Tema, kontrolün nereye ait olduğunu söyler ama hangisinin seçileceğine karar vermez. Karar risk puanından ve yükümlülüklerden çıkar. Yüksek puanlı bir teknik risk, teknolojik temadan bir kontrolü Bildirge'ye 'uygulanıyor' diye yazdırır.

Düşük puanlı bir risk, kontrolü dışarıda bırakabilir; yeter ki gerekçe yazılsın. İki kurum aynı Ek A listesine bakıp tamamen farklı bir Bildirge çıkarabilir. Çünkü risk puanları, faaliyet alanları ve müşteri beklentileri kurumdan kuruma değişir.

Bildirge'de üç hata sık görülür. Birincisi 93 satırın hepsine 'uygulanıyor' yazmaktır. Bu ilk bakışta güvenli görünür. Oysa denetçi her 'uygulanıyor' satırı için kanıt ister ve örnekleme yaparak birkaçını açar.

Kanıtı olmayan satır uygunsuzluk olur. İkincisi gerekçeyi kopyalayıp yapıştırmaktır. Otuz satırda aynı 'risk değerlendirmesi sonucu seçildi' cümlesi, hiçbir riski göstermez. Üçüncüsü paylaşılan sorumluluğu yanlış okumaktır.

Sistemler bulutta diye bulut ya da tedarikçi kontrollerini 'uygulanmıyor' işaretlemek yanlıştır. Sağlayıcı fiziksel veri merkezini korur. Hesapların, yetkilerin ve yapılandırmanın güvenliği ise kurumda kalır. Doğru kayıt, sağlayıcının payını güvence raporuyla, kurumun payını kendi kanıtıyla gösterir.

Bildirge yaşayan bir belgedir. Risk değerlendirmesi yenilendiğinde, kapsama yeni bir sistem girdiğinde ya da ciddi bir olaydan sonra güncellenir. Her güncelleme bir sürüm numarası ve onay tarihi taşır. Denetçi, Bildirge'nin tarihini risk kaydının tarihiyle karşılaştırır.

Risk kaydı Haziran'da değişmiş ama Bildirge Ocak'tan beri aynıysa, iki belge arasındaki bağ kopmuş demektir. Gözetim denetiminde ilk bakılan yerlerden biri budur. Altay Kargo bu yüzden Bildirge'yi her çeyreklik risk toplantısının gündemine koydu.