ISO 27001 ve BGYS

İlk on ders tek tek kontrolleri anlattı: şifreleme, sertifika, yetki, güvenlik duvarı, log, olay müdahalesi. Hepsinin cevaplamadığı bir soru kaldı: bunları kim, hangi düzende seçecek ve seçtiğini nasıl sürdürecek? Bir kurumda güvenlik, tek tek iyi kararların toplamı değildir; kararların tekrarlanabilir biçimde alındığı bir sistemdir. ISO 27001 tam olarak bunu tarifler ve şu tuhaf özelliğe sahiptir: neyi koruyacağını sana bırakır, nasıl karar verdiğini denetler. Bu ders standardı ezberletmez; standardın arkasındaki mantığı — varlık, sahiplik, risk kaydı, uygulanabilirlik bildirgesi, denetim döngüsü — ve belgenin neden güvenlik anlamına gelmediğini kurar.

01Ne öğreneceksin

02Yönetim sistemi ne demektir

Çoğu insan ISO 27001'i "uyulması gereken güvenlik kuralları listesi" sanır. Değildir. ISO 27001 bir BGYS — Bilgi Güvenliği Yönetim Sistemi — standardıdır ve bir yönetim sistemi, teknik bir yapı değil, karar üretme düzeneğidir: neyi koruyacağını nasıl belirlediğin, hangi riski neden kabul ettiğin, kararı kimin verdiği, kararın uygulandığını nasıl doğruladığın ve bozulduğunda nasıl düzelttiğin.

Standardın gövdesi (madde 4-10) şarttır, pazarlık edilmez: bağlam, liderlik, planlama, destek, operasyon, performans değerlendirme, iyileştirme. Sonundaki Annex A ise bir kontrol kataloğudur ve buradaki kontrollerin hepsini uygulamak zorunda değilsin — uygulamadığını gerekçelendirmek zorundasın. Bu ayrım standardın en çok yanlış bilinen yeridir ve sınavda ayırıcıdır.

2022 revizyonu. Eski sürümde Annex A'da 14 alan ve 114 kontrol vardı; 2022 sürümünde 4 tema ve 93 kontrol var. Sayı azaldı çünkü çoğu kontrol birleştirildi; ayrıca 11 yeni kontrol eklendi: tehdit istihbaratı, bulut hizmetlerinin kullanımı, BİT süreklilik hazırlığı, fiziksel güvenlik izleme, yapılandırma yönetimi, bilgi silme, veri maskeleme, veri sızıntısı önleme, izleme faaliyetleri, web filtreleme ve güvenli kodlama. Bu listeyi tanıman iki nedenle önemli: soruların bir kısmı doğrudan buradan gelir, ve yenilerin çoğu yazılımcının sorumluluk alanındadır — güvenli kodlama, veri maskeleme, yapılandırma yönetimi ve bilgi silme dördü de kod düzeyinde karşılık ister.

03Kapsam: en kritik ve en çok manipüle edilen karar

BGYS kurmanın ilk adımı kapsamı yazmaktır: hangi bilgi varlıkları, hangi süreçler, hangi organizasyon birimleri, hangi lokasyonlar ve hangi teknolojiler bu sistemin içindedir. Kapsam dar tutulursa belge almak kolaylaşır; geniş tutulursa belge kurumun gerçeğini yansıtır.

Klasik manipülasyon: kapsamı yalnız veri merkezine ya da tek bir hizmete daraltmak. Sertifika duvarda asılıdır, ama yazılım geliştirme ekibi, tedarikçi yönetimi ve son kullanıcı bilgisayarları kapsam dışıdır — yani ihlalin fiilen olacağı yerler kapsam dışıdır. Bu sahtekârlık değildir, standart buna izin verir; okumayı bilmeyen tarafın hatasıdır. Bir müşteri ya da mülakat sorusu olarak doğru refleks: "kapsam beyanını görebilir miyim?"

Kapsamın iki teknik zorunluluğu vardır. Birincisi arayüz ve bağımlılıkların tanımlanması: kapsam dışında olup kapsamı etkileyen her şey (bulut sağlayıcı, dış geliştirme firması, bordro hizmeti) tedarikçi güvenliği kontrolleriyle yönetilmek zorundadır — "kapsam dışı" demek "risk yok" demek değildir. İkincisi bağlam analizi: kurumun iç ve dış konuları ile ilgili tarafların beklentileri. Yazılımcı gözüyle bu soyut madde çok somut bir şeye dönüşür — uymak zorunda olduğun kurallar listesi: KVKK, sektör regülasyonu, müşteri sözleşmesindeki güvenlik ekleri, kamu kurumuysa Bilgi ve İletişim Güvenliği Rehberi (13. ders). Bu liste sonradan hatırlanan bir şey değil, kapsamın girdisidir.

04PDCA: BGYS'nin yıllık ritmi

14-02'de risk yönetimini bir döngü olarak görmüştün. BGYS'nin tamamı aynı döngüdür: Planla → Uygula → Kontrol et → Önlem al. Standardın 2022 metni PDCA kelimesini zorunlu tutmaz ama yapısı birebir odur. Önemli olan ezber değil, döngünün her adımının hangi kanıtı ürettiğidir; çünkü denetimde sorulan soru "yaptınız mı" değil, "yaptığınızı gösterin"dir.

Tablodaki "ürettiği kanıt" sütunu standardın gerçek yaptırımıdır: kaydı olmayan faaliyet yapılmamış sayılır. Bu, 14-10'da logla ilgili öğrendiğin cümlenin yönetişim düzeyindeki karşılığıdır — orada "log yoksa olay olmamıştır" diyorduk, burada "kayıt yoksa kontrol yoktur". Aynı disiplin, farklı katman.

05Varlık envanteri ve sahiplik

14-07'de saldırganların en çok kullandığı açıklardan birini görmüştün: kurumun kendi bilmediği sunucular. Cümleyi tekrar edelim, çünkü bu dersin merkezinde duruyor — bilmediğin sunucuyu yamayamazsın, envanterde olmayan veriyi koruyamazsın. Bu yüzden BGYS'nin ilk somut çıktısı bir varlık envanteridir.

Varlık yalnızca donanım değildir. Beş sınıfı ayırt et: bilgi (veritabanları, dosyalar, kaynak kodu, sözleşmeler, yedekler), yazılım (uygulamalar, işletim sistemleri, bağımlılıklar, lisanslar), fiziksel (sunucu, dizüstü, telefon, ağ cihazı, ortam), hizmet (bulut abonelikleri, internet, elektrik, dış hizmetler), insan (kritik bilgi ve yetkinlik taşıyan roller).

Her varlığın bir sahibi olmak zorundadır. 14-01'de yaptığımız ayrım burada resmî hâle gelir: sahip, varlığın iş değerini bilen ve risk kabul etme yetkisi olan kişidir (ör. İK sistemi için İK direktörü); emanetçi, onu işleten teknik kişidir (sistem yöneticisi, DBA, geliştirici). Emanetçi risk kabul edemez. Bu ayrım kâğıt üstünde bürokratik görünür, pratikte şunu engeller: yetkisiz bir kişinin "biz bu açığı kabul ettik" demesi.

Sınıflandırma envanterin ikinci yarısıdır: her bilgi varlığı bir gizlilik sınıfına konur (ör. açık / kurum içi / gizli / çok gizli) ve — asıl önemlisi — her sınıf için işleme kuralları yazılır: nasıl etiketlenir, nasıl saklanır, nasıl iletilir, kimlerle paylaşılır, nasıl imha edilir. En sık görülen hata, sınıflandırma yapıp işleme kuralı yazmamaktır; o zaman etiket dekoratif olur ve kimse davranışını değiştirmez.

06Risk kaydı ve uygulanabilirlik bildirgesi

14-02'de riskin nasıl hesaplandığını öğrendin. BGYS'nin eklediği şey belgelenmesi ve tekrarlanabilir olmasıdır. Kritik sıra şudur: önce kriterler yazılır — ölçekler, risk kabul eşiği, kimin kabul edebileceği — sonra değerlendirme yapılır. Tersi denetimde en klasik bulgudur: sonuç yüksek çıktı diye eşiği yükseltmek, riski değil belgeyi yönetmektir.

Son satır önemsiz görünür ama hattın en çok tekrarlanan cümlesidir: kabul edilen risk yazılır. 14-09'da bunu güvenli geliştirme tarafında görmüştün ("bilinçli kabul, görünmez ihmalden iyidir"); 16. hatta aynı disiplinin mimari karşılığını ADR olarak göreceksin. Üç yerde de aynı fikir: kaydedilmeyen karar, sonradan kimsenin sahiplenmediği bir kazaya dönüşür.

SoA — Uygulanabilirlik Bildirgesi (Statement of Applicability) BGYS'nin imza belgesidir ve denetçinin ilk baktığı yerdir. Annex A'daki her kontrol için dört şeyi söyler: uygulanabilir mi, uygulanıyor mu, neden (hangi risk ya da hangi mevzuat gerektiriyor), nasıl (hangi prosedür/sistemle). Hariç tutmalar gerekçelidir — "yazılım geliştirmiyoruz" diyen bir kurum güvenli kodlama kontrolünü hariç tutabilir, ama geliştiriyorsa tutamaz.

Denetimde en sık çıkan tutarsızlık: SoA "uyguluyoruz" diyor ama risk işleme planı ya da kayıtlar bunu doğrulamıyor. Denetçi teknik derinliğe inmeden, yalnız üç belgeyi (risk kaydı ↔ risk işleme planı ↔ SoA) yan yana koyarak bulgu yazabilir.

07Annex A: dört tema ve yazılımcının payı

Yazılımcıyı doğrudan bağlayan teknolojik kontroller: A.8.8 teknik açıklıkların yönetimi (14. derse köprü: tarama ve yama), A.8.9 yapılandırma yönetimi, A.8.11 veri maskeleme, A.8.12 veri sızıntısı önleme, A.8.16 izleme faaliyetleri (14-10), A.8.25 güvenli geliştirme yaşam döngüsü (14-09), A.8.26 uygulama güvenlik gereksinimleri, A.8.28 güvenli kodlama, A.8.29 geliştirme ve kabulde güvenlik testi, A.8.31 geliştirme/test/üretim ortamlarının ayrılması, A.8.32 değişiklik yönetimi, A.8.33 test bilgisi.

08Politika, prosedür, talimat, kayıt

BGYS'nin dokümantasyonu dört katmanlıdır ve karıştırılması en yaygın acemi hatasıdır:

• Politika — ne ve neden. Kısa, üst yönetim onaylı, bağlayıcı niyet beyanı. "Tüm ayrıcalıklı erişimler çok faktörlü doğrulama gerektirir."
• Prosedür — kim, ne zaman, hangi sırayla. "Ayrıcalıklı hesap talebi şu formla açılır, varlık sahibi onaylar, 90 günde bir gözden geçirilir."
• Talimat / standart — nasıl, teknik adımlar. "Sunucularda MFA şu araçla, şu ayarlarla kurulur." Kodlama standardı da buraya girer.
• Kayıt — kanıt. Onay formu, log çıktısı, erişim gözden geçirme tutanağı, eğitim katılım listesi.

Zorunlu dokümante bilginin çekirdeği: kapsam, BG politikası, risk değerlendirme ve işleme yöntemi, risk değerlendirme raporu, risk işleme planı, SoA, güvenlik hedefleri, yetkinlik kayıtları, izleme-ölçme sonuçları, iç denetim programı ve raporları, yönetimin gözden geçirmesi çıktıları, uygunsuzluk ve düzeltici faaliyet kayıtları.

Tuzak: internetten indirilen politika şablonunu kurum adıyla değiştirip yayımlamak. Şablon, kurumda karşılığı olmayan taahhütlerle doludur; denetçi politikayı okur, uygulamayı sorar, karşılığını bulamaz ve kendi yazdığın cümleden bulgu alırsın. Kural basittir: yazdığın her cümleyi uygulamak zorundasın — bu yüzden az ama gerçekten uygulanabilir yaz, sonra genişlet.

09Denetim, uygunsuzluk ve "belge ≠ güvenlik"

İç denetim kurumun kendi kendini denetlemesidir; yılda en az bir kez, bir programa göre yapılır ve bağımsızlık şartı vardır: kimse kendi işlettiği süreci denetleyemez. Küçük kurumlarda bu, dışarıdan bağımsız bir denetçiyle çözülür.

Belgelendirme denetimi akredite bir belgelendirme kuruluşu tarafından yapılır: Aşama 1 dokümantasyon ve hazırlık incelemesi, Aşama 2 uygulamanın yerinde denetimi. Belge üç yıl geçerlidir; arada gözetim denetimleri (genelde yıllık) ve üçüncü yılın sonunda yeniden belgelendirme vardır.

Düzeltme ile düzeltici faaliyeti karıştırma. Düzeltme, semptomu giderir: "açık kalan portu kapattık". Düzeltici faaliyet, tekrarını engeller: "port açma işlemi artık değişiklik yönetiminden geçiyor, ayrıca haftalık dış yüzey taraması kuruldu". Denetçi ikincisini görmezse bulguyu kapatmaz. Bu, 14-10'daki "çıkarılan ders" adımının aynısıdır.

Yönetimin gözden geçirmesi yılda en az bir kez toplanır ve girdileri bellidir: önceki kararların durumu, değişen iç/dış konular, güvenlik hedeflerine göre performans, uygunsuzluklar ve olaylar, denetim sonuçları, ilgili taraf geri bildirimleri, risk değerlendirmesinin durumu ve iyileştirme önerileri. Çıktısı da bellidir: karar — kaynak tahsisi, hedef değişikliği, sistem değişikliği. Tutanaksız toplantı yapılmamış sayılır.

10Mini alıştırma — bir düğümün BGYS izdüşümü

11Kendini sına

BGYS nedir? ISO 27001 ile ISO 27002 arasındaki fark nedir ve Annex A kontrollerinin tamamı zorunlu mudur?

BGYS (Bilgi Güvenliği Yönetim Sistemi), bilgi güvenliğinin tek tek önlemlerle değil, risk temelli ve tekrarlanabilir bir karar ve gözden geçirme düzeneğiyle yönetilmesidir: bağlam ve kapsam belirlenir, roller ve yetkiler atanır, risk değerlendirilir ve işlenir, kontroller uygulanır, performans ölçülür, iç denetim ve yönetimin gözden geçirmesi yapılır, uygunsuzluklar düzeltici faaliyetle kapatılır — yani PDCA. ISO/IEC 27001 bu sistemin şartlarını koyan ve kurumun kendisine göre belgelendirildiği standarttır; ISO/IEC 27002 ise Annex A kontrollerinin nasıl uygulanacağını anlatan rehberdir ve ona göre belgelendirme yapılmaz (27005 risk yönetimi rehberi, 27017/27018 bulut ek rehberleridir). Annex A kontrollerinin tamamı zorunlu değildir: kurum risk değerlendirmesine ve tabi olduğu mevzuata göre hangilerini uygulayacağını seçer, ama uygulamadığını gerekçelendirmek zorundadır ve bu gerekçeler Uygulanabilirlik Bildirgesi'nde (SoA) yazılır. Standardın gövdesi (madde 4-10) ise pazarlığa açık değildir. 2022 revizyonunda Annex A 14 alan / 114 kontrolden 4 tema / 93 kontrole düşmüş, aralarında tehdit istihbaratı, bulut kullanımı, yapılandırma yönetimi, bilgi silme, veri maskeleme, DLP, izleme, web filtreleme ve güvenli kodlama gibi 11 yeni kontrol eklenmiştir.

Varlık envanteri neden BGYS'nin temelidir? Varlık sahibi ile emanetçi arasındaki fark nedir?

Envanter temeldir çünkü korumanın kapsamı envanterle sınırlıdır: bilinmeyen sunucu yamalanamaz, envanterde olmayan veritabanı yedeklenemez ve sınıflandırılamaz, listelenmemiş bağımlılık taranamaz. 14-07'deki gerçek ilk erişim vektörlerinin başında bu geliyordu. Envanter beş sınıfı kapsar: bilgi, yazılım (ve bağımlılıklar), fiziksel, hizmet, insan. Her varlık bir sınıflandırma alır ve her sınıf için işleme kuralı yazılır — etiket var ama saklama/iletim/imha kuralı yoksa sınıflandırma dekoratiftir. Sahip, varlığın iş değerini bilen, koruma gereksinimlerini belirleyen ve artık riski kabul etme yetkisi olan kişidir; emanetçi ise onu günlük olarak işleten teknik kişidir (sistem yöneticisi, DBA, geliştirici). Emanetçi risk kabul edemez; edebiliyorsa kurumda yetki modeli bozuktur. Pratikte envanterin en zayıf yeri gölge BT ve bulutta kısa ömürlü kaynaklardır; çözüm elle tutulan listeler değil, otomatik keşiftir (bulut envanter API'si, ağ/uç nokta taraması, kod tarafında SBOM). Kişisel veri envanteri de bu envanterin bir kesitidir ve KVKK/VERBİS yükümlülüğünün girdisidir.

Uygulanabilirlik Bildirgesi (SoA) nedir, neden bu kadar önemlidir? Risk kaydında artık risk neden yazılır?

SoA, Annex A'daki her kontrol için "uygulanabilir mi, uygulanıyor mu, hangi risk veya mevzuat nedeniyle, hangi prosedür/sistemle" sorularını cevaplayan belgedir. Önemi üç katmanlıdır: (1) BGYS'nin risk değerlendirmesi ile uygulanan kontroller arasındaki izlenebilirlik zinciridir; (2) denetçinin ilk baktığı ve diğer belgelerle çapraz doğruladığı yerdir — risk kaydı, risk işleme planı ve SoA arasındaki tutarsızlık en klasik bulgudur; (3) hariç tutmaların gerekçesini kayda geçirerek keyfîliği engeller. Artık risk (kontroller uygulandıktan sonra kalan risk) yazılır çünkü hiçbir kontrol riski sıfırlamaz; yazılmazsa iki kötü şey olur: kurum kendini olduğundan güvenli sanır, ve olay gerçekleştiğinde kimsenin sahiplenmediği bir karar ortaya çıkar. Kabul, varlık sahibi tarafından ve yazılı yapılır, bir gözden geçirme tarihi taşır. Aynı disiplin 14-09'da güvenli geliştirmede (bilinçli risk kabulü) ve 16. hatta mimari kararlarda (ADR) karşımıza çıkar. Kritik sıra kuralı: risk kabul kriterleri değerlendirmeden önce yazılır; sonuç yüksek çıktı diye eşiği yükseltmek riski değil belgeyi yönetmektir.

İç denetim ile belgelendirme denetimi arasındaki fark nedir? "ISO 27001 belgemiz var" cümlesi güvenli olduğumuz anlamına gelir mi?

İç denetim kurumun kendi BGYS'sini, planlı bir program dâhilinde ve bağımsızlık şartıyla (kimse kendi işlettiği süreci denetlemez) yılda en az bir kez denetlemesidir; amacı belge almak değil, sistemin çalıştığını doğrulamak ve eksikleri belgelendirme denetiminden önce yakalamaktır. Belgelendirme denetimi akredite bir kuruluş tarafından yapılır: Aşama 1 dokümantasyon incelemesi, Aşama 2 yerinde uygulama denetimi; belge üç yıl geçerlidir, arada yıllık gözetim denetimleri ve sonunda yeniden belgelendirme vardır. Bulgular majör uygunsuzluk, minör uygunsuzluk ve iyileştirme fırsatı olarak sınıflanır; kapatma için düzeltme (semptomu gidermek) yetmez, düzeltici faaliyet (kök nedeni bulup tekrarını engellemek) gerekir. Hayır, belge güvenli olunduğu anlamına gelmez: standart bir yönetim sisteminin varlığını ve şartlara uygunluğunu doğrular, her kontrolün teknik etkinliğini ya da saldırıya dayanıklılığını değil; üstelik denetim örneklemeyle çalışır ve yalnız kapsam beyanındaki alanı kapsar. Bu yüzden doğru sorular "belgeniz var mı" değil, "kapsam ne, hangi sürüm, SoA'da ne hariç tutulmuş, son denetimde kaç majör bulgu çıkmış" sorularıdır. Belge bir taban çizgisidir, bir garanti değil.

12Sınav köşesi