CompTIA SY0-701: Yönetişim, Risk Yönetimi ve Uyum — Çalışma kılavuzu
Şunun bir parçası: CompTIA Security+ SY0-701 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: CompTIA sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.
Yönetişim, Risk Yönetimi ve Uyumluluk — topluca GRC olarak kısaltılan — teknik güvenlik kontrollerini kurumsal stratejiye, yasal yükümlülüklere ve finansal gerçekliğe bağlayan bağlayıcı dokudur. Güvenlik duvarları ve uç nokta ajanları sistemleri savunurken, GRC bunların neden var olduğunu, kimin sahibi olduğunu ve etkinliklerinin nasıl ölçülüp raporlandığını tanımlar. Olgun bir GRC programı, güvenliği geçici bir teknik disiplin olmaktan çıkarıp denetlenebilir, tekrarlanabilir bir iş fonksiyonuna dönüştürür.
Güvenlik Yönetişimi ve Temelleri
Güvenlik yönetişimi, bir kuruluşun güvenlik duruşunu yönlendiren yetki, hesap verebilirlik ve karar alma çerçevesidir. En kritik unsuru yönetici desteğidir, çünkü liderlik taahhüdü olmadan politikalar rafa kaldırılır ve bütçeler buharlaşır. Yönetişim üç katmanlı dokümantasyon üretir: politikalar (liderlik tarafından onaylanmış, üst düzey, zorunlu niyet beyanları), standartlar (spesifik, ölçülebilir gereksinimler — örneğin, “tüm harici uç noktalar için minimum TLS 1.3”), prosedürler veya SOP’ler (adım adım operasyonel talimatlar) ve kılavuzlar (önerilen ancak zorunlu olmayan uygulamalar). Bu katmanları karıştırmak sık yapılan bir hatadır; bir politika ne ve neden olduğunu belirtirken, bir prosedür nasıl yapılacağını belirtir.
Yaygın kurumsal politikalar arasında, çalışanların kurumsal sistemleri kullanımını düzenleyen Kabul Edilebilir Kullanım Politikası (AUP), parola ve erişim politikaları, veri sınıflandırma politikaları, olay müdahale politikaları ve değişiklik yönetimi politikaları bulunur. Her biri teknik kontroller ve disiplin süreçleri aracılığıyla uygulanır.
Risk Değerlendirmesi ve Kantitatif Analiz
Risk yönetimi bir yaşam döngüsünü takip eder: varlıkları ve tehditleri belirle, olasılık ve etkiyi değerlendir, riski ele al ve sürekli izle. Kapsamın belirlenmesi ilk ve genellikle hafife alınan bir adımdır — bu, hangi sistemlerin, iş birimlerinin, veri türlerinin ve tehdit senaryolarının dahil olduğunu belirleyerek değerlendirmenin sınırlarını tanımlar. Tanımlanmış bir kapsam olmadan, değerlendirmeler sınırsız hale gelir ve güvenilmez sonuçlar üretir.
Kantitatif (nicel) risk analizi, riskleri nesnel olarak karşılaştırmak için parasal değerler kullanır. Temel formüller şunlardır:
SLE (Single Loss Expectancy) = Asset Value × Exposure Factor
ARO (Annualized Rate of Occurrence) = Expected incidents per year
ALE (Annualized Loss Expectancy) = SLE × ARO
Örneğin, bir fidye yazılımı olayının her gerçekleşmede 15.000 dolara mal olacağı ve üç yılda iki kez gerçekleşmesi bekleniyorsa, ARO 2 ÷ 3 ≈ 0,667’ye eşit olur, bu da ALE’yi yıllık 15.000 $ × 0,667 = 10.000 $ yapar. Sık yapılan bir hata, ARO’yu yıllık bir temele normalleştirmeyi ihmal etmektir — eğer sıklık birden fazla yıl üzerinden verilmişse, buna göre bölünmelidir. Başka bir tuzak, bir kontrolü haklı çıkarmak için tek başına SLE’yi kullanmaktır; 0,01 ARO’ya sahip 500.000 dolarlık bir SLE (ALE = 5.000 $), nadiren yıllık 50.000 dolarlık bir kontrolü gerektirir.
Buna karşılık, kalitatif (nitel) analiz, sıralı ölçekler (Düşük/Orta/Yüksek veya 1–5) ve ısı haritaları kullanır. Kesin finansal veriler mevcut olmadığında daha hızlı ve kullanışlıdır, ancak maliyet-fayda kararları için hassasiyetten yoksundur.
Risk iştahı ve risk toleransı, liderliğin ne kadar risk kabul etmeye istekli olduğunu tanımlar — iştah, kabul edilebilir riskin stratejik seviyesiyken, tolerans bu seviyeden kabul edilebilir sapmayı tanımlar. Bunlar, riski ele alma kararlarından önce tanımlanmalıdır, çünkü eylem gerektiren eşiği belirlerler.
Riski Ele Alma Stratejileri
Değerlendirildikten sonra, her risk dört stratejiden biri kullanılarak ele alınır. Hafifletme, kontroller aracılığıyla olasılığı veya etkiyi azaltır — yama yönetimi, segmentasyon, MFA. Devretme, finansal sonuçları üçüncü bir tarafa, en yaygın olarak siber sigorta veya sözleşmesel tazminat yoluyla aktarır. Kaçınma, faaliyeti durdurarak riski ortadan kaldırır — örneğin, belirli veri türlerini saklamayı reddetmek. Kabul etme, genellikle ele alma maliyetinin ALE’yi aştığı durumlarda, herhangi bir eylemde bulunmamak için alınan resmi, belgelenmiş bir karardır.
Tehlikeli bir yanılgı, sigortayı hafifletmenin bir alternatifi olarak görmektir. Sigorta, finansal etkiyi devreder ancak ihlalleri, itibar hasarını veya düzenleyici cezaları önlemek için hiçbir şey yapmaz; ki bunların birçoğu siber poliçelerden açıkça hariç tutulur. Benzer şekilde, bir telafi edici kontrol — birincil kontrolün uygulanamaz olduğu durumlarda alternatif bir önlem — dağıtmak, kabul etme değil, bir hafifletme şeklidir. Eğer eski bir sistem MFA’yı destekleyemiyorsa ve bunun yerine gelişmiş loglama ile segmente edilmiş bir VLAN üzerinde izole ediliyorsa, bu segmentasyon kabul edilmiş bir risk değil, bir telafi edici kontroldür.
Risk Kaydı
Risk kaydı, risk yönetiminin merkezi dokümanıdır. Her bir tanımlanmış riski, sorumlu sahibi, olasılık ve etki derecelendirmeleri, mevcut kontroller, ele alma stratejisi, artık risk, eşikler ve gözden geçirme tarihleri ile birlikte belgeler. İyi tutulmuş bir kayıt, liderliğin harcamaları önceliklendirmesini sağlar ve denetçileri risk kararlarının izlenebilir olduğu konusunda tatmin eder. Tipik bir kayıt girdisi şöyle olabilir:
Risk ID: R-2024-017
Description: Unpatched Apache Struts on public web tier
Owner: Director of Infrastructure
Likelihood: High | Impact: High | Inherent Risk: Critical
Treatment: Mitigate — WAF virtual patch + emergency change window
Residual Risk: Medium | Threshold: Any exploit PoC published
Review Cadence: Weekly until closed
Risk değerlendirmeleri tek seferlik değil, tekrarlayan olmalıdır. Tehdit ortamları, iş süreçleri ve üçüncü taraf ilişkileri sürekli değişir; yıllık bir değerlendirmenin tetikleyici yeniden değerlendirmelerle (büyük satın almalar, yeni düzenlemeler, olaylar) desteklenmesi kabul edilen standarttır.
Sözleşmeler ve Hizmet Anlaşmaları
Sözleşme araçları, taraflar arasındaki yükümlülükleri resmîleştirir. Ana Hizmet Sözleşmesi (Master Service Agreement - MSA), tüm ilişkiyi yöneten genel yasal şartları belirler. İş Kapsamı Belgesi (Statement of Work - SOW), bir MSA altında faaliyet gösterir ve belirli bir çalışma için spesifik teslimatları, zaman çizelgelerini ve kabul kriterlerini tanımlar. Hizmet Seviyesi Anlaşması (Service Level Agreement - SLA), ölçülebilir performans taahhütlerini belirtir — çalışma süresi yüzdeleri, yanıt süreleri, hedeflere ulaşılamaması durumunda uygulanacak cezalar gibi. Yaygın bir hata, SOW ve SLA’yı birbirine karıştırmaktır: bir SOW “3. çeyreğe kadar bir müşteri portalı teslim edin” derken, bir SLA “portal %99,9 kullanılabilirliği ve dört saatlik bir olay müdahale süresini sürdürecektir” der.
Gizlilik Sözleşmesi (Non-Disclosure Agreement - NDA), taraflar arasında paylaşılan gizli bilgileri korur. Mutabakat Zaptı (Memorandum of Understanding - MOU), genellikle bağlayıcı olmayan bir iş birliği niyetini ifade eder. İş Ortaklığı Anlaşmaları (Business Partnership Agreements - BPA), ortak girişimleri yönetir ve Sistemler Arası Bağlantı Güvenlik Anlaşmaları (Interconnection Security Agreements - ISA), iki kuruluşun sistemlerini doğrudan bağladığında teknik ve güvenlik gereksinimlerini tanımlar.
Üçüncü Taraf Riski ve Tedarik Zinciri
Üçüncü taraf risk yönetimi, bir kuruluşun güvenlik duruşunun, verilerine veya sistemlerine erişimi olan her tedarikçiyi kapsadığı gerçeğini ele alır. Durum tespiti, sözleşme imzalanmadan önce başlar — finansal istikrarın, güvenlik sertifikalarının ve olay geçmişinin incelenmesi — ve ilişki boyunca periyodik yeniden değerlendirme, denetim hakkı maddeleri ve sürekli izleme hizmetleri aracılığıyla devam eder.
Tedarik zinciri riski, bunu donanım, yazılım ve aygıt yazılımı (firmware) kökenine kadar genişletir. Yazılım Malzeme Listeleri (Software Bills of Materials - SBOMs), kod imzalama doğrulaması ve tedarikçi güvenlik anketleri giderek daha zorunlu hale gelmektedir. 2020’deki SolarWinds ihlali, güvenilir bir yazılım güncelleme kanalının nasıl bir saldırı vektörüne dönüşebileceğini tam olarak göstermiştir: saldırganlar, Orion derleme (build) sürecine bir arka kapı (SUNBURST) yerleştirmiş, bu arka kapı daha sonra kriptografik olarak imzalanmış ve yaklaşık 18.000 müşteriye meşru bir güncelleme olarak dağıtılmıştır. Hiçbir çevre denetimi bunu durduramadı çünkü kötü amaçlı kod, bilinen bir tedarikçiden gelen güvenilir, imzalı bir paket olarak geldi. Buradan çıkarılacak ders, tedarik zinciri güveninin varsayılması değil, sürekli olarak doğrulanması gerektiğidir.
Beyanlar, Denetimler ve Mevzuata Uygunluk
Bağımsız güvence çeşitli şekillerde olabilir. Lisanslı CPA firmaları tarafından AICPA standartları altında hazırlanan SOC 2 Tip II raporları, bir hizmet kuruluşunun kontrollerini belirli bir süre boyunca (genellikle 6–12 ay) Güven Hizmetleri Kriterleri’ne (Trust Services Criteria) göre değerlendirir. SOC 2 Tip I, tek bir anı kapsar ve çok daha zayıf bir kanıt niteliğindedir. SOC 1, finansal raporlama kontrollerini ele alır; SOC 3 ise kamuya açık bir özettir. ISO/IEC 27001 sertifikasyonu, işler durumda bir Bilgi Güvenliği Yönetim Sistemi’nin varlığını gösterir.
Kritik bir ayrım: bir beyan (attestation) resmi bir ifadedir — bazen tedarikçinin kendisi tarafından (bir öz beyan) ve bazen de bağımsız bir denetçi tarafından yapılır. Bir tedarikçinin öz beyanı, bağımsız bir üçüncü taraf denetim raporuna göre çok daha az kanıt değeri taşır. “SOC 2 raporunuzu” talep edip karşılığında bir pazarlama PDF’ini kabul etmek, sık karşılaşılan bir tedarik hatasıdır; gerekli olan belge, denetçi firmanın görüş mektubunu içeren imzalı asıl rapordur.
Yasal düzenlemeler belirli yükümlülükler getirir. PCI DSS, kart sahibi verilerini yönetir ve ağ segmentasyonu, üç ayda bir yapılan ASV taramaları, yıllık sızma testleri gibi kuralcı teknik gereksinimler içerir. GDPR, AB veri sahipleri için haklar tesis eder, 72 saat içinde ihlal bildirimini zorunlu kılar ve küresel yıllık gelirin %4’üne varan para cezalarına izin verir. HIPAA, ABD’deki sağlık bilgilerini korur, SOX, finansal raporlama bütünlüğünü yönetir ve GLBA, finans kurumları için geçerlidir. Uyumluluk bir tavan değil, asgari bir başlangıç noktasıdır — PCI uyumlu olmak, güvende olmak anlamına gelmez, sadece değerlendirme anında tanımlanmış bir taban çizgisinin karşılandığı anlamına gelir.
Pratik Senaryo: Yasal Cezayla Sonuçlanan bir GRC Başarısızlığı
Bölgesel bir sağlık ağı, faturalandırma platformunu, güvenlik durum tespiti yapmadan veya sözleşmeye denetim hakkı maddeleri eklemeden üçüncü taraf bir tedarikçiye devretti. Tedarikçi, 340.000 hasta kaydını ifşa eden bir fidye yazılımı (ransomware) saldırısına uğradı. Sağlık ağı, bir İş Ortağı Sözleşmesi (Business Associate Agreement - BAA) incelemesi yapmadığı, tedarikçinin güvenlik kontrollerine dair hiçbir kanıtı olmadığı ve ilişkiye yönelik bir risk değerlendirmesi yapmadığı için HHS OCR, ağı HIPAA Güvenlik Kuralı’nı ihlal etmekten suçlu buldu. Sonuçlanan anlaşma, 1,2 milyon dolarlık bir para cezasını ve iki yıllık bir düzeltici eylem planını içeriyordu. Sağlık ağının kendi bünyesindeki teknik kontroller yeterliydi; başarısızlık tamamen yönetişimdeydi — tedarikçi risk programı yok, sözleşmeye bağlı güvenlik yükümlülükleri yok, periyodik yeniden değerlendirme yok. Bu senaryo, GRC başarısızlıklarının soyut uyumluluk eksiklikleri olmadığını; somut, ölçülebilir finansal ve itibari zararlar doğurduklarını göstermektedir.
Tüm alanlar · Kimlik ve Erişim Yönetimi →
Bu soruları çözün → · ExamRoll.io’da süreli pratik →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Sınavınızı geçin →