Kurumsal Siber Güvenlik Nedir? Kapsamlı Rehber ve Yol Haritası

Pazartesi sabahı saat 08.15’te sipariş sistemi yanıt vermiyor. Operasyon ekibi önce sıradan bir altyapı arızası olduğunu düşünüyor. Ardından dosya sunucularındaki bazı kayıtların adının değiştiği, birkaç yönetici hesabıyla gece saatlerinde oturum açıldığı ve yedekleme panelinde başarılı görünen son job’ın geri yüklenemediği anlaşılıyor.

Kurumun güvenlik ürünü yok değildir. Firewall vardır. EDR kuruludur. SIEM’e log akıyordur. Bir önceki yıl internet sitesine sızma testi de yaptırılmıştır. Buna rağmen olay büyümüştür. Çünkü EDR’nin ürettiği ilk alert sahiplenilmemiş, ayrıcalıklı hesapların MFA coverage’ı tamamlanmamış, sızma testinin kapsamına VPN ve identity altyapısı girmemiş, yedeğin geri dönüş testi ise hiç yapılmamıştır.

Araçlar çalışmış, fakat güvenlik programı birlikte çalışmamıştır.

Kurumsal siber güvenliğin en sık yanlış anlaşıldığı nokta tam olarak budur. Siber güvenlik, satın alınan ürünlerin toplamı değildir. Aynı şekilde yılda bir kez yapılan pentest, alınan bir ISO/IEC 27001 belgesi veya çalışanlara gönderilen farkındalık videosu da tek başına güvenlik programı oluşturmaz.

Bu rehberde siber güvenlik nedir, güncel tehdit ortamı nasıl okunmalı, ofansif ve defansif güvenlik çalışmaları nerede birleşir, ISO/IEC 27001 ve KVKK hangi çerçeveyi sağlar, bir kurum olgunluğunu nasıl ölçebilir ve uygulanabilir bir 0-3-6-12 aylık yol haritasını nasıl kurabilir sorularını ayrıntılı biçimde ele alacağız.

1. Siber güvenlik nedir?

Siber güvenlik, bilgi sistemlerinin ve bu sistemlerin desteklediği iş süreçlerinin yetkisiz erişim, kötüye kullanım, kesinti, değişiklik, veri kaybı ve diğer dijital tehditlere karşı korunmasıdır. Kurumsal perspektifte korunan şey yalnızca sunucu veya veri değildir. Müşteriye verilen hizmet, üretim kapasitesi, finansal işlem, fikri mülkiyet, marka itibarı, yasal yükümlülük ve karar alma kabiliyeti de aynı tablonun içindedir.

Klasik bilgi güvenliği yaklaşımı üç temel özelliği korumayı amaçlar:

• Confidentiality: Bilgiye yalnızca yetkili tarafların erişebilmesi
• Integrity: Bilginin ve sistem davranışının yetkisiz şekilde değiştirilememesi
• Availability: Sistem ve verinin ihtiyaç duyulduğunda kullanılabilir olması

Gerçek bir kurumsal program bunlara ek olarak authenticity, accountability, traceability, privacy, safety ve operational resilience gibi sonuçları da ele alır. Örneğin üretim hattındaki bir OT sisteminde yalnızca verinin gizliliğine bakmak yeterli değildir. Yanlış komutun fiziksel güvenliğe etkisi, hattın ne kadar süre durabileceği ve güvenli çalışma durumuna nasıl dönüleceği de güvenlik kararının parçasıdır.

Kurumsal siber güvenliğin cevaplaması gereken altı soru

Güvenlik programının seviyesi ne olursa olsun yönetim şu sorulara tutarlı cevap verebilmelidir:

1. 1İş açısından vazgeçilmez hizmetlerimiz, verilerimiz ve bağımlılıklarımız hangileri?
2. 2Bunlara kim, hangi cihazla ve hangi koşullarda erişebiliyor?
3. 3En olası ve en ağır sonuçlu saldırı senaryolarımız neler?
4. 4Kontrollerimizin gerçekten çalıştığını hangi kanıtla biliyoruz?
5. 5Bir ihlali ne kadar sürede fark eder, sınırlar ve temizleriz?
6. 6Kritik hizmeti kabul edilebilir veri kaybıyla ne kadar sürede geri getirebiliriz?

Bu soruların biri cevapsızsa güvenlik ürünlerinin sayısı kuruma güvence vermez. Özellikle asset inventory, identity inventory ve data flow bilinmiyorsa sonraki yatırımlar tahmine dayanır.

Siber güvenlik bir IT konusu mudur?

IT ekibi güvenlik kontrollerinin önemli bölümünü işletir, fakat cyber risk’in sahibi tek başına IT değildir. Satın alma ekibi tedarikçi riskini, insan kaynakları işe giriş ve ayrılış süreçlerini, hukuk ve privacy ekipleri veri işleme yükümlülüklerini, ürün ekipleri secure development gereksinimlerini, iş birimleri ise kesinti ve veri kaybının gerçek etkisini yönetir.

Yönetim kurulunun rolü teknik ayar seçmek değildir. Risk appetite’ı tanımlamak, kritik hizmetleri ve hesap verebilirliği belirlemek, yeterli kaynağı ayırmak ve artık riskin bilinçli biçimde kabul edildiğini doğrulamaktır.

NIST Cybersecurity Framework 2.0’ın önceki beş function’a Govern function’ını eklemesi de bu noktayı güçlendirir. Govern, Identify, Protect, Detect, Respond ve Recover birlikte çalışmadığında güvenlik ya yalnızca önleme ürünlerine ya da olay çıktıktan sonra müdahaleye sıkışır.

Siber güvenlik nasıl sağlanır?

Tek bir ürün veya proje ile değil, tekrarlanan bir yönetim döngüsüyle:

1. 1Kritik iş hizmetleri ve supporting asset’ler belirlenir.
2. 2Threat scenario’lar ve iş etkileri değerlendirilir.
3. 3Mevcut control’ler ve coverage boşlukları ölçülür.
4. 4Risk treatment önceliğine göre control’ler uygulanır.
5. 5Ofansif testler ve control validation çalışmalarıyla etkinlik doğrulanır.
6. 6Telemetry, detection ve Incident Response hazırlığı işletilir.
7. 7Olaylar, test bulguları ve iş değişiklikleriyle program yeniden güncellenir.

Güvenlik burada bitiş çizgisi olan bir proje değildir. Kurum yeni uygulama açtığında, cloud’a geçtiğinde, şirket satın aldığında, kritik tedarikçi değiştirdiğinde veya threat landscape değiştiğinde risk modeli de değişir.

2. Güncel tehdit ortamı nasıl okunmalı?

Tehdit ortamını anlamak, yılın en popüler saldırı türlerini bir slayta koymak değildir. Kurumun sektörü, coğrafi varlığı, technology stack’i, internet exposure’ı, tuttuğu veri ve kesinti toleransı ile threat actor kabiliyetlerini eşleştirmek gerekir.

ENISA Threat Landscape 2025, 1 Temmuz 2024 ile 30 Haziran 2025 arasında analiz edilen 4.875 olay içinde ransomware’i AB açısından en etkili tehdit olarak değerlendiriyor. Aynı çalışmada phishing gözlemlenen initial access yöntemlerinin yaklaşık yüzde 60’ını, vulnerability exploitation ise yüzde 21,3’ünü oluşturuyor. Bu oranlar her Türkiye şirketi için birebir olasılık hesabı değildir. Ancak identity güvenliği, hızlı vulnerability remediation ve dayanıklı recovery süreçlerinin neden aynı yol haritasında bulunması gerektiğini açıkça gösterir.

Ransomware artık yalnızca dosya şifreleme problemi değildir

Modern ransomware operasyonunda saldırgan önce erişim elde edebilir, ayrıcalık yükseltebilir, yedekleme altyapısını hedefleyebilir ve hassas veriyi dışarı çıkarabilir. Şifreleme son aşama olabilir. Kurum dosyalarını geri yüklese dahi veri sızıntısı, şantaj, müşteri bildirimi ve operasyon kesintisi devam edebilir.

Bu yüzden ransomware hazırlığı yalnızca endpoint üzerinde anti-malware çalıştırmakla sınırlanamaz. Identity, network segmentation, privileged access, egress visibility, immutable backup, restore test, crisis communication ve Incident Response birlikte sınanmalıdır. NIST’in Haziran 2026’da yayımladığı IR 8374 Rev. 1 de ransomware risk yönetimini CSF 2.0’ın bütün function’ları boyunca ele alır.

Tedarik zinciri saldırısında güvenilen bağlantı saldırı yoluna dönüşür

Kurum iyi korunsa bile kullandığı software package, managed service provider, remote support hesabı, CI/CD runner, code signing anahtarı veya SaaS integration saldırgan için daha ekonomik bir yol sunabilir.

Tedarikçi risk değerlendirmesinde yalnızca anket göndermek yeterli değildir. Şu sorular teknik kanıtla ele alınmalıdır:

• Tedarikçinin hangi data ve environment’lara erişimi var?
• Erişim persistent mı, ihtiyaç anında mı açılıyor?
• Tedarikçi hesabında phishing-resistant MFA uygulanıyor mu?
• Software artifact’ların kaynağı ve integrity’si doğrulanabiliyor mu?
• Güvenlik olayı bildirim süresi sözleşmede açık mı?
• Subprocessor zinciri biliniyor mu?
• Erişim kesildiğinde hizmet güvenli şekilde devam edebiliyor mu?

Tedarik zinciri güvenliği “tedarikçi güvenlidir” varsayımı üzerine kurulmaz. Tedarikçi compromise edildiğinde etkiyi sınırlayacak architecture üzerine kurulur.

Phishing bir e-posta probleminden önce identity problemidir

Kullanıcı sahte sayfaya şifresini yazabilir, infostealer browser session’ını çalabilir, help desk sosyal mühendislikle MFA reset’i yapabilir veya saldırgan mevcut bir e-posta thread’ine girerek ödeme bilgisini değiştirebilir.

Farkındalık eğitimi önemlidir, ancak kimlik doğrulamanın tek kontrolü insan dikkati olamaz. Phishing-resistant MFA, conditional access, device posture, session protection, help desk verification ve anormal oturum detection’ı aynı saldırı senaryosunu farklı noktalarda keser.

Insider risk her zaman kötü niyetli çalışan demek değildir

Bir çalışan veriyi bilinçli olarak çıkarabilir. Fakat daha sık görülen senaryoların bir bölümü aşırı yetki, yanlış recipient, herkese açık cloud link’i, kişisel cihaz kullanımı, kontrolsüz API token’ı veya işten ayrılan kullanıcının kapatılmamış hesabı gibi kasıtsız ya da süreç kaynaklı olaylardır.

Insider risk programı çalışanı sürekli şüpheli ilan etmemelidir. Veri sınıflandırma, need-to-know access, segregation of duties, loglama, DLP’nin doğru context’te kullanımı ve adil investigation prosedürüyle ilerlemelidir.

Bilinen açıkların istismarı hâlâ güçlü bir initial access yoludur

Internet-facing VPN, firewall, remote management ürünü, web application veya unutulmuş bir servis yeni bir CVE açıklandığında saatler içinde değerli hedef hâline gelebilir. Buna rağmen patch kararı yalnızca CVSS sırasına göre verildiğinde aktif exploitation görülen bir açık, teorik olarak daha yüksek skorlu fakat erişilemeyen bir bulgunun gerisinde kalabilir.

Doğru önceliklendirme CVSS’i, CISA Known Exploited Vulnerabilities gibi exploitation kanıtlarını, exposure’ı, asset criticality’yi ve saldırı yolundaki rolü birlikte değerlendirir.

Her trend kurum için aynı önceliği taşımaz

Bir e-ticaret platformu için account takeover ve ödeme fraud’u öncelikli olabilir. Üretim kurumunda OT kesintisi ve safety etkisi öne çıkabilir. B2B SaaS sağlayıcısında tenant isolation ve cloud identity, hukuk bürosunda client confidentiality, finans kuruluşunda ise fraud, availability ve yoğun düzenleyici beklenti birlikte ele alınır.

Threat Intelligence değerini, kurumun kontrol seçimini ve detection içeriğini değiştirdiğinde üretir. Genel threat feed’lerini toplamak tek başına tehdit odaklı güvenlik programı kurmaz.

3. Katmanlı savunma: Defense in Depth ne anlama gelir?

Defense in Depth, aynı işi yapan çok sayıda ürünü üst üste koymak değildir. Bir saldırı adımı önleyici kontrolden geçerse sonraki kontrolün saldırıyı tespit etmesi, ilerlemeyi zorlaştırması veya etkiyi sınırlaması için bağımsız güvenlik katmanları tasarlamaktır.

Örneğin saldırgan bir kullanıcının parolasını ele geçirmiş olsun:

• Phishing-resistant MFA doğrudan girişi engelleyebilir.
• Conditional access bilinmeyen veya non-compliant cihazı durdurabilir.
• Least privilege hesabın erişebildiği kaynakları sınırlar.
• Network segmentation başka environment’lara geçişi zorlaştırır.
• EDR credential theft ve suspicious process davranışını görebilir.
• SIEM sıra dışı coğrafya, impossible travel veya yeni cihaz sinyalini ilişkilendirebilir.
• Data access monitoring olağan dışı indirmeyi fark edebilir.
• Incident Response ekibi hesabı ve session’ları hızla revoke edebilir.

Bu kontrollerin hiçbiri kusursuz değildir. Birlikte tasarlandıklarında tek bir hata bütün savunmanın hatası olmaktan çıkar.

Etkili katmanların ortak özelliği

Kurumsal bir architecture genellikle şu katmanları içerir:

• Governance: Risk ownership, politika, exception, bütçe ve third-party beklentileri
• Identity: MFA, lifecycle, PAM/PIM, service identity ve authorization
• Endpoint ve workload: Secure configuration, patch, EDR, application control
• Network: Segmentation, secure remote access, egress control ve visibility
• Application: Secure SDLC, SAST, SCA, threat modeling, code review ve pentest
• Data: Classification, encryption, key management, access monitoring ve retention
• Detection: Merkezi loglama, use case, alert triage, Threat Intelligence ve threat hunting
• Response ve recovery: Playbook, karar yetkisi, forensic readiness, backup ve restore

Katman sayısı kadar katmanlar arasındaki boşluk önemlidir

Bir control dashboard’da “deployed” görünürken gerçek coverage düşük olabilir. EDR agent’ı sunucuların yüzde 92’sinde kuruluysa geride kalan yüzde 8’in hangi sistemler olduğu belirleyicidir. SIEM’e authentication log’u geliyor olabilir, fakat cloud control plane veya SaaS audit log’ları gelmiyorsa saldırı zinciri eksik kalır.

Bu nedenle her kritik control için en az şu beş bilgi tutulmalıdır:

1. 1Hangi risk senaryosunu azaltıyor?
2. 2Hangi asset ve identity’leri kapsıyor?
3. 3Beklenen güvenlik davranışı nedir?
4. 4Başarısız olduğu nasıl fark edilir?
5. 5Etkinliği ne zaman ve nasıl test edildi?

“Satın alındı” veya “kuruldu” bir güvenlik sonucu değildir. Coverage, configuration, telemetry ve test evidence birlikte görülmelidir.

Zero Trust, Defense in Depth’in yerine mi geçer?

Hayır. Zero Trust, ağ içinde olmanın kendiliğinden güven sağlamadığı, erişim kararlarının identity, device, resource ve context temelinde verildiği bir architecture yaklaşımıdır. NIST SP 800-207’nin ifadesiyle odak network segment’inden resource’a kayar.

Bu yaklaşım segmentation, endpoint health, strong authentication, authorization ve monitoring ihtiyacını ortadan kaldırmaz. Tam tersine bu kontrolleri daha ince taneli ve sürekli karar üretecek şekilde birbirine bağlar.

4. Ofansif güvenlik: Kontroller gerçekten çalışıyor mu?

Ofansif güvenlik, kurumu korkutucu bir açık listesiyle baş başa bırakmak için değil, saldırganın kullanabileceği yolları kontrollü koşullarda ortaya çıkarmak ve güvenlik varsayımlarını kanıtla sınamak için uygulanır.

Her assessment aynı soruyu cevaplamaz. Scanner bilinen weakness’leri geniş ölçekte arar. Pentest belirli scope içindeki zafiyetlerin exploitability’sini ve etkisini doğrular. Secure Code Review root cause’u kod içinde inceler. Red Team ise bir iş hedefine giden saldırı zinciri boyunca prevention, detection ve response performansını birlikte ölçer.

Sızma testi

Sızma testi, tanımlı scope içindeki web, API, mobil, iç ağ, dış ağ veya cloud attack surface’i üzerinde zafiyetleri araştırır ve güvenli sınırlar içinde exploitation ile doğrular. Ana amaç olabildiğince sessiz kalmak değil, kapsam dahilindeki gerçek riskleri belirlemek ve remediation için teknik kanıt üretmektir.

Scanner çıktısının ötesine geçen bir pentest authorization, business logic, chained weakness, trust boundary ve gerçek impact üzerinde derinleşir. Test türleri, aşamaları, metodolojileri ve firma seçim kriterleri için Sızma Testi Nedir? Kapsamlı Rehber sayfası bu alanın merkez içeriğidir.

Red Team

Red Team, “kaç açık var?” sorusundan çok, “belirli bir saldırgan gerçek bir hedefe ilerlerken kurum bunu önleyebilir, görebilir ve sınırlayabilir mi?” sorusunu yanıtlar. Senaryo, Threat Intelligence ve kurumun risk profiliyle şekillenir. Rules of Engagement ve ölçülebilir objective ile yürütülür.

Her kurum doğrudan Red Team ile başlamamalıdır. Asset inventory, temel hardening, logging, SOC ownership ve Incident Response akışı hazır değilse çalışma bilinen eksikleri tekrar kanıtlamakla kalabilir. Red Team hazırlığı, assumed breach seçenekleri, MITRE ATT&CK kullanımı ve raporlama ayrıntıları Red Team Nedir? Kapsamlı Rehber içinde ele alınmaktadır.

Zafiyet tarama

Vulnerability scanning, geniş bir asset kümesinde bilinen CVE, eksik patch, insecure configuration ve exposure işaretlerini tekrarlanabilir biçimde arar. Gücü sıklık ve coverage’dır. Sınırı ise her finding’in gerçek exploitability’sini ve business impact’ini tek başına belirleyememesidir.

Tek seferlik tarama, güvenlik programı değildir. Discovery, triage, remediation, exception, re-scan ve trend takibi bir araya geldiğinde zafiyet yönetimi oluşur. Bu döngünün teknik ve operasyonel kurulumu için Zafiyet Tarama Nedir? Kapsamlı Rehber okunabilir.

Kaynak kod analizi

Kaynak kod analizi, weakness’in uygulama içinde nasıl oluştuğunu ve güvenlik kararlarının nasıl uygulandığını source code düzeyinde araştırır. SAST tekrarlanabilir pattern ve data flow analizi sağlar. Uzman Secure Code Review ise business logic, object-level authorization, tenant isolation ve framework context’i gibi otomasyonun sınırlı kaldığı alanları inceler.

SAST, SCA, DAST ve manuel incelemenin doğru dağılımı Kaynak Kod Analizi (SAST) Nedir? Güvenli Kod İnceleme Rehberi içinde ayrıntılı olarak açıklanmaktadır.

Ofansif ve defansif güvenlik hizmetleri aynı sistemin iki tarafıdır

Purple Team yaklaşımı, Red ve Blue Team’in teknik bulguyu birlikte detection ve response iyileştirmesine dönüştürür. BAS ise belirli testleri sık ve standardize biçimde tekrarlamak için değerlidir. Aralarındaki ölçüm farklarını Purple Team, Red Team ve BAS: Hangi Çalışma Neyi Ölçer? yazısında bulabilirsiniz.

5. Defansif güvenlik: SOC, SIEM, EDR/MDR ve Incident Response

Defansif güvenliğin görevi yalnızca alert görmek değildir. Normal davranıştan sapmayı anlamlandırmak, saldırı zincirini farklı telemetry kaynaklarından birleştirmek, doğru containment kararını zamanında almak ve hizmeti güvenli şekilde çalışır durumda tutmaktır.

SOC bir oda veya vardiya tablosu değildir

SOC, güvenlik olaylarını izleyen ve yöneten insan, süreç, technology ve karar yetkisinin bütünüdür. İster kurum içinde ister dış hizmet modeliyle çalışsın şu yetenekler açık olmalıdır:

• Hangi sistemlerin ve identity kaynaklarının izlendiği
• Alert’lerin severity ve business criticality’ye göre nasıl triage edildiği
• Use case’lerin hangi threat scenario’lara bağlandığı
• Kimlerin containment uygulayabildiği
• Mesai dışı escalation’ın nasıl yürüdüğü
• False positive ve missed detection’ların nasıl iyileştirmeye dönüştüğü
• Incident ile alert ayrımının nasıl yapıldığı

Ticket kapatma süresi tek başına SOC başarısı değildir. Yanlışlıkla hızlı kapatılmış bir true positive, iyi performans gibi görünebilir.

SIEM log deposundan daha fazlası olmalıdır

SIEM farklı kaynaklardan gelen event’leri toplar, normalize eder, ilişkilendirir ve detection üretimine temel sağlar. Fakat SIEM’e her log’u gönderme yaklaşımı hem maliyeti hem gürültüyü büyütebilir.

Öncelik kritik use case’ler olmalıdır. Örneğin:

• Privileged account’a yeni MFA yöntemi eklenmesi
• Dormant hesabın etkinleşmesi
• EDR disable veya uninstall girişimi
• Cloud audit log’un durması
• Yeni API key oluşturulması ve kısa sürede yüksek veri erişimi
• Service account’ın ilk kez interactive logon yapması
• Backup policy veya retention değişikliği
• Domain admin group üyeliğinin değişmesi

Her use case için required telemetry, detection logic, expected false positive, owner, response playbook ve test sonucu tutulmalıdır.

EDR ile MDR aynı şey değildir

EDR endpoint ve workload üzerinde process, file, registry, network ve diğer davranışlardan telemetry üretir. İzolasyon veya process termination gibi response aksiyonlarını destekleyebilir. MDR ise bu ve diğer güvenlik araçlarının uzmanlar tarafından izlenmesi, araştırılması ve belirli sözleşme sınırlarında müdahale edilmesi hizmetidir.

MDR satın alındığında sorumluluk tamamen devredilmiş olmaz. Sağlayıcının hangi aksiyonu kendiliğinden alabileceği, hangisinde kurum onayı bekleyeceği, olay sırasında kimin business context sağlayacağı ve evidence’ın nasıl korunacağı önceden belirlenmelidir.

Detection engineering neden ayrı bir çalışma alanıdır?

Hazır vendor rule’ları yaygın saldırıları yakalayabilir. Kurumun custom application’ı, admin workflow’u, cloud mimarisi ve kritik business process’i için yeterli olmayabilir.

Detection engineering şu döngüyü işletir:

1. 1Threat scenario ve kritik davranış seçilir.
2. 2Gerekli telemetry ve field kalitesi doğrulanır.
3. 3Detection logic yazılır.
4. 4Kontrollü test veya Red/Purple Team faaliyetiyle tetiklenir.
5. 5Analyst’in gördüğü context ve playbook değerlendirilir.
6. 6Gürültü azaltılır, coverage kaydı güncellenir.

Bu yaklaşım SIEM’deki rule sayısını değil, önemli saldırı davranışlarının görülebilirliğini artırır.

6. İnsan katmanı: Farkındalık ve phishing simülasyonu nasıl değer üretir?

“İnsan en zayıf halkadır” cümlesi hem kolay hem eksiktir. Çalışan, kötü tasarlanmış authentication akışının, sınırsız erişimin veya doğrulamasız ödeme sürecinin yerine geçemez. İnsan katmanı güvenlik mimarisinin suçlanacak parçası değil, doğru davranışı kolaylaştıracak ve şüpheli durumu erken bildirecek bir sensördür.

Yılda bir eğitim neden yeterli değildir?

Generic video, çalışanların gerçek iş akışındaki kararlarını değiştirmeyebilir. Finans ekibinin Business Email Compromise riski, developer’ın secret ve dependency riski, help desk’in identity verification riski, yönetici asistanının hassas doküman paylaşım riski aynı değildir.

Eğitim programı role-based olmalı ve şu konularla iş akışına bağlanmalıdır:

• Şüpheli e-posta, chat ve telefon talebini hızlı bildirme
• MFA fatigue ve sahte login sayfasını tanıma
• Ödeme veya hesap değişikliğinde out-of-band verification
• Hassas veri sınıflandırma ve güvenli paylaşım
• Password manager ve phishing-resistant MFA kullanımı
• Kişisel cloud, removable media ve unmanaged device riski
• Developer’lar için secret, code review ve dependency sorumluluğu
• Yönetici ve privileged user’lar için targeted social engineering

Phishing simülasyonu çalışanı yakalamak için yapılmamalıdır

Sadece tıklama oranını düşürmeye odaklanan program, çalışanları testten kaçınmaya yöneltebilir. Daha değerli ölçümler şunlardır:

• Şüpheli mesajın bildirilme oranı
• İlk doğru bildirime kadar geçen süre
• Service desk’in şüpheli reset talebini durdurma oranı
• Aynı risk sınıfında tekrar eden davranış
• Bildirimden sonra SOC’un investigation başlatma süresi
• Kritik ekiplerde role-based eğitim coverage’ı

Gerçek olayda erken bildirim, hiç hata yapmama beklentisinden daha gerçekçi ve değerlidir.

7. Kimlik ve erişim yönetimi: Modern saldırı yüzeyinin merkezi

Cloud, SaaS, remote work ve API yoğun mimarilerde klasik network perimeter tek başına sınır değildir. Kullanıcı hesabı, workload identity, access token, API key ve CI/CD credential kurumun yeni kontrol düzlemidir.

MFA gereklidir, fakat her MFA aynı dayanıklılığı sağlamaz

SMS kodu, push notification ve authenticator OTP hiç MFA olmamasından daha iyidir. Ancak phishing proxy, SIM swap veya MFA fatigue gibi saldırılara karşı aynı seviyede direnç sunmaz. CISA’nın MFA rehberi, kurumların FIDO/WebAuthn tabanlı phishing-resistant MFA’ya geçiş planlamasını önerir.

Geçiş bir gecede tamamlanamayabilir. Önce şu gruplar ele alınmalıdır:

1. 1Global admin, domain admin ve cloud administrator hesapları
2. 2Remote access ve VPN kullanıcıları
3. 3Finans, insan kaynakları ve yönetici hesapları
4. 4Developer, CI/CD ve production erişimi olan ekipler
5. 5Help desk ve identity recovery yetkisine sahip roller
6. 6Third-party ve support hesapları

Least privilege yalnızca rol sayısını azaltmak değildir

Least privilege, bir identity’ye görevini yapması için gereken minimum yetkinin, gereken süre ve context içinde verilmesidir. Kalıcı admin yetkisini daha küçük bir admin rolüyle değiştirmek her zaman yeterli olmaz.

Olgun yaklaşım:

• Joiner, mover ve leaver lifecycle’ını otomatikleştirir
• Role ve entitlement owner’larını tanımlar
• Privileged access’i JIT ve süreli hale getirir
• Riskli işlemlerde approval ve step-up authentication kullanır
• Service account’larda interactive login’i kapatır
• Human ve machine identity’leri ayrı yönetir
• Access review’ları sadece imza toplamak için değil, gerçek kullanım verisiyle yürütür
• Break-glass hesaplarını izler ve düzenli test eder

Authentication ile authorization karıştırılmamalıdır

MFA kullanıcının kimliğine güveni artırır. O kullanıcının her kayda erişmesi gerektiğini kanıtlamaz. Uygulama içinde object-level authorization, tenant isolation ve function-level control ayrıca uygulanmalıdır.

Birçok IDOR olayı authenticated kullanıcı üzerinden gerçekleşir. Sorun login’in atlanması değil, giriş yapmış kullanıcının başka kullanıcıya ait nesneye erişebilmesidir. Bu zafiyet sınıfının neden kalıcı olduğunu IDOR Açığı Neden Hâlâ Bu Kadar Yaygın? yazısında teknik örneklerle inceleyebilirsiniz.

8. Zafiyet yönetimi döngüsü: Bulmak değil, riski kapatmak

Bir kurumun binlerce finding üretmesi, zafiyetlerini yönettiğini göstermez. Değer, doğru asset’in taranması, bulgunun context içinde önceliklendirilmesi, owner’a atanması, güvenli şekilde düzeltilmesi ve kapanışın re-scan veya retest ile doğrulanmasıyla oluşur.

Sağlıklı bir zafiyet yönetimi akışı

1. 1Discovery: Host, application, API, cloud resource, container image ve external exposure belirlenir.
2. 2Assessment: Authenticated scanning, SAST, SCA, cloud configuration assessment ve gerekli diğer teknikler uygulanır.
3. 3Validation: False positive, version detection hatası ve duplicate finding’ler ayıklanır.
4. 4Prioritization: Severity, exploitability, exposure, asset criticality, compensating control ve business impact birlikte değerlendirilir.
5. 5Remediation: Patch, configuration, code change, isolation veya control iyileştirmesi uygulanır.
6. 6Exception: Hemen giderilemeyen risk için owner, gerekçe, compensating control ve expiry date kaydedilir.
7. 7Verification: Re-scan veya manuel retest ile gerçek kapanış doğrulanır.
8. 8Learning: Root cause ve tekrar eden pattern’den standard, golden image, regression test veya SAST rule’u üretilir.

Bu döngünün neden tek seferlik taramadan farklı olduğu Zafiyet Tarama Nedir? Zafiyet Yönetimi ve Düzenli Tarama Rehberi içinde daha geniş biçimde açıklanmaktadır.

CVSS neden tek başına risk sırası değildir?

CVSS teknik severity için ortak dil sağlar. Fakat varlığın internete açık olup olmadığını, exploit’in aktif kullanılıp kullanılmadığını, etkilenen verinin değerini ve attack path üzerindeki rolünü tek başına söylemez.

Örneğin internete kapalı bir laboratuvar sistemindeki CVSS 9.8 finding ile aktif exploitation görülen ve müşteri verisine giden internet-facing sistemdeki CVSS 8.1 finding aynı sırayla yönetilmemelidir.

Pratik bir öncelik modeli şu girdileri birlikte kullanır:

• CVSS base ve temporal bilgi
• CISA KEV kaydı veya güvenilir exploitation evidence
• EPSS gibi exploit probability sinyali
• Internet exposure ve erişim ön koşulu
• Asset ve data criticality
• Privilege ve lateral movement değeri
• Mevcut preventive ve detective control’ler
• Remediation maliyeti ve service impact

SLA tek başına çözüm değildir

“Critical 7 gün, High 30 gün” gibi SLA’lar yararlı olabilir. Ancak owner belli değilse, bakım penceresi yoksa, patch dependency’si çözülmemişse veya exception süresiz açılıyorsa dashboard yaşlanan ticket’larla dolar.

Gerçek program yalnızca SLA compliance’ı değil, exposure süresini, tekrar açılan bulguyu, scan coverage’ını, exception age’ini ve root cause tekrarını izler.

9. Uyum ve standartlar: ISO/IEC 27001, KVKK, NIST CSF ve PCI DSS

Uyum ile güvenlik aynı şey değildir. Uyum, belirli bir yükümlülük veya standardın beklediği kontrollerin ve evidence’ın gösterilmesidir. Güvenlik ise gerçek threat scenario karşısında riskin kabul edilebilir seviyeye indirilmesidir.

Aralarında güçlü bir ilişki vardır, fakat biri diğerini otomatik olarak kanıtlamaz. Denetimde eksiksiz görünen bir control pratikte yetersiz coverage’a sahip olabilir. Tersine teknik olarak güçlü bir ekip, karar ve evidence sürecini kayıt altına almadığı için uyum gereksinimini karşılayamayabilir.

ISO/IEC 27001 ne sağlar?

ISO/IEC 27001:2022, Information Security Management System için gereksinimleri tanımlar. Risk assessment, risk treatment, sorumluluk, ölçüm, internal audit ve continual improvement etrafında yönetim sistemi kurar.

Standard bir ürün listesi değildir. Her kuruma aynı control’ü aynı şekilde uygulamasını söylemez. Kurum scope’unu, bağlamını, ilgili tarafları, risklerini ve risk treatment kararlarını tanımlar. Certification çoğu kurum için gönüllü veya sözleşmesel bir tercih olabilir. Belirli sektör ve müşteri ilişkilerindeki ek yükümlülükler ayrıca değerlendirilmelidir.

Belge almak, her sistemin güvenli olduğunu veya hiç ihlal yaşanmayacağını göstermez. Güçlü uygulama, ISMS kararlarını gerçek asset, vulnerability, incident ve test verisiyle besler.

KVKK siber güvenlik açısından ne getirir?

6698 sayılı Kişisel Verilerin Korunması Kanunu’nun 12. maddesi kapsamında veri sorumlusu, kişisel verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek, verinin muhafazasını sağlamak için uygun güvenlik düzeyine yönelik gerekli teknik ve idari tedbirleri almakla yükümlüdür. Kişisel Verileri Koruma Kurumu’nun veri güvenliği açıklaması bu yükümlülüğün kapsamını ve risk temelli yaklaşımı açıklar.

Kişisel Verileri Koruma Kurumu, tek bir güvenlik modeli öngörülmediğini, önlemlerin veri sorumlusunun yapısına, faaliyetine, tabi olduğu risklere ve işlenen verinin niteliğine uygun olması gerektiğini açıklar. Veri sorumlusu ayrıca gerekli denetimleri yapmak veya yaptırmakla yükümlüdür.

Bu çerçeve “KVKK için bir kez pentest yaptırmak yeterlidir” şeklinde yorumlanmamalıdır. Data inventory, access control, logging, employee süreçleri, vendor yönetimi, retention, Incident Response ve düzenli teknik doğrulama birlikte ele alınır. İhlal bildirimi, hukuki değerlendirme ve süre yönetimi hukuk ve privacy ekipleriyle yürütülmelidir.

NIST CSF 2.0 yol haritasında nasıl kullanılır?

NIST CSF 2.0, her ölçekte ve sektörde kurumun cyber risk sonuçlarını Govern, Identify, Protect, Detect, Respond ve Recover function’ları altında değerlendirmesine yardımcı olur. Prescriptive bir teknoloji listesi vermez.

Current Profile mevcut durumu, Target Profile ise iş hedefleri ve risk appetite doğrultusunda ulaşılmak istenen sonucu gösterir. İki profil arasındaki gap, yatırım ve iyileştirme backlog’unu oluşturmak için kullanılabilir.

PCI DSS hangi durumda önemlidir?

PCI DSS, payment account data işleyen, saklayan veya ileten environment’lar için ilgili kapsam ve doğrulama modeline göre teknik ve operasyonel gereksinimler getirir. PCI DSS v4.0.1 altında vulnerability scan, penetration testing, access control, logging, secure configuration ve diğer kontrol aileleri birlikte ele alınır.

Quarterly ASV scan’in geçilmesi tek başına PCI DSS uyumunu göstermez. PCI SSC de ASV raporunun yalnızca ilgili scanning gereksinimine kanıt sunduğunu, diğer gereksinimlerin incelendiği anlamına gelmediğini belirtir.

Hangi çerçeve ne için kullanılmalı?

10. Bulut güvenliği temelleri

Cloud’a geçmek güvenlik sorumluluğunu ortadan kaldırmaz. Sorumluluğun hangi parçasının cloud provider’a, hangi parçasının müşteriye ait olduğunu service model’e göre değiştirir. Provider fiziksel datacenter ve belirli managed service katmanlarını korurken müşteri çoğu senaryoda identity, data, configuration, workload, application ve tenant içi activity’den sorumlu olmaya devam eder.

Bu ayrım IaaS, PaaS ve SaaS arasında değiştiği gibi aynı provider içindeki farklı servislerde de değişebilir. “Cloud zaten güvenlidir” veya “on-premises her zaman daha güvenlidir” genellemeleri karar vermek için yeterli değildir.

Cloud control plane en kritik attack surface’lerden biridir

Cloud ortamında bir administrator token’ı, erişim anahtarı veya CI/CD credential’ı çok sayıda kaynağı kısa sürede değiştirebilir. Saldırganın her virtual machine’e ayrı ayrı girmesi gerekmez. Identity ve control plane üzerinden yeni key oluşturabilir, loglamayı kapatabilir, snapshot alabilir, public access açabilir veya yeni workload çalıştırabilir.

Öncelikli kontroller şunlardır:

• Root veya break-glass hesaplarında güçlü MFA ve ayrı izleme
• Human identity ve workload identity ayrımı
• Kısa ömürlü credential ve JIT privileged access
• Organization, subscription ve account seviyesinde guardrail
• Cloud audit log’larının merkezi ve değiştirilemez hedefe aktarılması
• Public exposure ve riskli security group değişikliklerinin izlenmesi
• Secret’ların code, image ve pipeline log’unda tutulmaması
• Key management ve rotation sorumluluğunun belirlenmesi
• Production ile development account’larının ayrılması
• Backup ve recovery kaynağının compromise edilmiş tenant’tan korunması

Misconfiguration tek sorun değildir

Cloud security çoğu zaman public bucket örneğine indirgenir. Oysa gerçek attack path birden fazla zayıflığın birleşiminden oluşabilir:

1. 1Developer repository’sinde uzun ömürlü access key bulunur.
2. 2Key’in rolü gereğinden geniş yetkilidir.
3. 3İlgili environment’ta organization policy guardrail’i yoktur.
4. 4Saldırgan secret manager’dan başka credential’lar okur.
5. 5Cloud audit log’ları SOC’a gitmediği için erişim fark edilmez.
6. 6Data snapshot’ı farklı account’a paylaştırılır.

Tek tek bakıldığında “medium” görülen yanlışlar, birlikte kritik veri sızıntısına dönüşür.

IaC ve pipeline güvenliği neden önemlidir?

Infrastructure as Code, güvenlik baseline’ını version control ve code review içine taşıma imkânı verir. Aynı zamanda hatalı template’in yüzlerce kaynağa tekrarlanması riskini de oluşturur.

Cloud güvenliği deployment sonrasında CSPM taramasıyla başlamamalıdır. Planlanan değişiklik:

• IaC scanning
• Policy as Code
• Secret scanning
• Dependency ve container image scanning
• Signed artifact ve provenance doğrulaması
• Pull request review
• Least-privilege runner
• Deployment sonrası configuration validation

ile pipeline boyunca kontrol edilmelidir.

Cloud pentest scope’u açıkça belirlenmelidir

Cloud provider’ın izin verdiği testler, tenant ownership, managed service sınırları, third-party SaaS bağımlılıkları ve production safety kuralları önceden doğrulanmalıdır. Yalnızca public IP listesi vermek cloud attack surface’i temsil etmeyebilir. IAM, storage, serverless, container orchestration, secret store, API gateway ve CI/CD integration’ları kapsam kararına dahil edilmelidir.

11. Olay müdahale ve iş sürekliliği

Incident Response, olay gerçekleştiğinde ilk kez toplanan insanların doğaçlama yaptığı süreç olmamalıdır. Kim karar verecek, kim sistemi izole edebilecek, hangi log’lar korunacak, hukuk ve privacy ekipleri ne zaman devreye girecek, müşteriye kim bilgi verecek ve kritik hizmet hangi sırayla geri dönecek önceden belirlenmelidir.

NIST SP 800-61 Rev. 3, Incident Response’u yalnızca “olay çıktıktan sonra” başlayan ayrı bir yaşam döngüsü olarak değil, CSF 2.0’ın bütün function’larına entegre bir cyber risk management capability olarak ele alır. Bu bakış önemlidir. Varlık ve data flow bilinmiyorsa analiz yavaşlar. Log yoksa detection ve forensic çalışma zayıflar. Recovery hedefi tanımlı değilse containment kararı bile iş birimleriyle çatışabilir.

Incident Response planı neleri içermelidir?

• Incident sınıfları ve severity kriterleri
• Incident commander ve karar yetkisi
• Teknik, yönetim, hukuk, privacy, iletişim ve iş birimi rolleri
• Mesai içi ve dışı iletişim yolları
• Third-party, cloud provider ve sigorta iletişimleri
• Evidence collection ve chain of custody yaklaşımı
• Containment için önceden yetkilendirilmiş aksiyonlar
• Kritik system ve data dependency haritası
• Düzenleyici ve sözleşmesel bildirim değerlendirme akışı
• Müşteri ve medya iletişim onay süreci
• Recovery öncelikleri, RTO ve RPO
• Post-incident review ve takip aksiyonları

Planın PDF olarak bulunması yeterli değildir. İletişim bilgilerinin güncel, yetkilerin uygulanabilir ve playbook’ların gerçek technology stack ile uyumlu olması gerekir.

Playbook, saldırı türüne göre karar akışını somutlaştırır

Genel planın yanında en kritik senaryolar için teknik playbook hazırlanmalıdır. İlk set genellikle şunları kapsar:

• Ransomware ve destructive attack
• Business Email Compromise
• Privileged account compromise
• Cloud credential exposure
• Web application veya API ihlali
• Kişisel veri sızıntısı
• Insider data exfiltration
• DDoS ve kritik hizmet kesintisi
• Third-party compromise

Her playbook detection source, ilk doğrulama adımı, containment seçenekleri, business impact, evidence ihtiyacı, escalation ve recovery kontrolünü tanımlamalıdır. “Cihazı kapat” gibi tek satırlık öneriler delil kaybına veya operasyonel zarara yol açabilir. Aksiyonlar environment ve olay context’iyle değerlendirilmelidir.

Backup varsa recovery garanti midir?

Hayır. Backup job’ının başarılı görünmesi, verinin doğru, temiz ve kullanılabilir şekilde geri dönebileceğini kanıtlamaz.

Dayanıklı recovery için:

• Backup scope’u kritik hizmet dependency’lerini kapsamalıdır.
• Kopyalardan en az biri saldırganın normal admin path’inden ayrı korunmalıdır.
• Deletion ve retention değişiklikleri ayrı yetki ve alert gerektirmelidir.
• Restore işlemi düzenli ve ölçümlü test edilmelidir.
• Recovered environment’a compromised credential veya persistence taşınmamalıdır.
• RTO ve RPO gerçek test sonuçlarıyla doğrulanmalıdır.
• İş birimi yalnızca sunucunun açıldığını değil, hizmetin uçtan uca çalıştığını onaylamalıdır.

Tabletop exercise neden değerlidir?

Tabletop teknik sistemi etkilemeden karar ve iletişim akışını sınar. İyi bir senaryo, katılımcılara sırayla yeni bilgiler verir. Örneğin önce EDR alert’i, sonra müşteri şikâyeti, ardından data exfiltration kanıtı ve medyadan gelen soru ortaya çıkabilir.

Amaç kişileri sınavdan geçirmek değil, belirsizlik altında karar vermeyi ve ekipler arası bağımlılıkları görmek olmalıdır. Çıktı yalnızca “tatbikat yapıldı” kaydı değil, owner ve deadline atanmış iyileştirme listesi olmalıdır.

12. Siber güvenlik olgunluk modeli: Nereden başlanır?

Olgunluk, kurumun kaç araca sahip olduğunu değil, risk kararlarını ne kadar tutarlı, ölçülebilir ve sürdürülebilir verebildiğini gösterir. Küçük fakat kritik kontrolleri iyi işleten bir kurum, pahalı ürünleri düşük coverage ile kullanan büyük bir kurumdan bazı alanlarda daha olgun olabilir.

Tek bir genel puan da yanıltıcıdır. Kurum identity’de gelişmiş, application security’de başlangıç seviyesinde, recovery’de ise kritik boşluklara sahip olabilir. Bu nedenle olgunluk domain bazında ölçülmeli, overall skor kadar en zayıf kritik capability de görünür tutulmalıdır.

Olgunluk seviyesine göre önerilen aksiyonlar

Baseline assessment nasıl yapılır?

İlk değerlendirmede yüzlerce soruluk checklist’e boğulmak yerine kritik business service seçilip uçtan uca izlenebilir:

1. 1Hizmetin sahibi kim?
2. 2Hangi application, identity, data, network ve supplier’a bağlı?
3. 3Kabul edilebilir kesinti ve veri kaybı nedir?
4. 4En önemli threat scenario’lar hangileri?
5. 5Prevent, Detect, Respond ve Recover control’lerinin coverage’ı nedir?
6. 6Son test evidence’ı ne zaman üretildi?
7. 7Açık gap’in risk owner’ı ve hedef tarihi kimde?

Bu yöntem güvenlik durumunu iş diline çevirir ve “her şeyi aynı anda düzeltme” baskısını azaltır.

Red Team’e hazır olmak bir olgunluk göstergesi midir?

Red Team yaptırmış olmak tek başına olgunluk göstergesi değildir. Bulgular SOC, architecture, hardening ve Incident Response backlog’una dönüşüyor, detection gap’leri retest ediliyor ve yönetim objective sonuçlarını risk kararında kullanıyorsa çalışma değer üretir.

Temel güvenlik hijyeni ve görünürlük henüz oturmamışsa önce sızma testi, zafiyet yönetimi, log coverage ve tabletop daha fazla risk azaltabilir. Ayrıntılı karar çerçevesi Her Kurumun Red Team’e İhtiyacı Var mı? yazısında yer alır.

13. KOBİ ve büyük kurumlar için öncelikler nasıl değişir?

KOBİ daha küçük attack surface’e sahip olabilir, fakat bu otomatik olarak düşük risk anlamına gelmez. Tek bir ERP, e-posta tenant’ı, e-ticaret platformu veya managed service provider’a yüksek bağımlılık, olayın kurumun tamamını durdurmasına neden olabilir. Büyük kurumda ise çok sayıda business unit, legacy system, acquisition ve third-party bağlantısı governance ile coverage sorununu büyütür.

KOBİ için temel yaklaşım

Sınırlı kaynak, “hiçbir şey yapılamaz” anlamına gelmez. Önce en yüksek leverage sağlayan kontroller seçilmelidir:

• Kritik hizmet, hesap ve veri inventory’si
• E-posta, remote access ve admin hesaplarında güçlü MFA
• Managed endpoint’lerde patch ve EDR coverage
• Ayrı ve tested backup
• Internet-facing varlıkların düzenli taranması
• E-posta ve payment change için doğrulama prosedürü
• External IT sağlayıcısının erişim ve sorumluluk sınırları
• Basit fakat güncel Incident Response iletişim planı
• Yüksek riskli web application ve API’ler için sızma testi

KOBİ için her capability’yi içeride kurmak ekonomik olmayabilir. MDR, managed vulnerability management veya fractional CISO gibi hizmetler kullanılabilir. Ancak scope, SLA, decision authority ve evidence ownership sözleşmede açık olmalıdır.

Büyük kurum için temel yaklaşım

Büyük kurumlarda sorun çoğu zaman ürün eksikliğinden çok standardizasyon ve visibility farkıdır:

• Business unit’ler arasında farklı identity ve endpoint politikaları
• Sahipsiz legacy application’lar
• Acquisition sonrası birleşmeyen tenant ve network’ler
• Fazla sayıda security tool ve duplicate telemetry
• Global politika ile yerel operasyon arasındaki boşluk
• Third-party access’in merkezi görünmemesi
• Exception’ların süresiz kalması
• Finding ownership’in ekipler arasında kaybolması

Merkezi güvenlik ekibi guardrail, ortak telemetry, minimum baseline ve risk governance sağlamalıdır. Product ve business ekipleri ise kendi service riskinin owner’ı olmalı, remediation’ı yalnızca merkezi ekibe bırakmamalıdır.

Öncelik farkı, kalite farkı değildir

KOBİ daha dar scope’ta güçlü temel kontroller kurabilir. Büyük kurum daha gelişmiş SOC ve Red Team capability’sine ihtiyaç duyabilir. İki durumda da aynı prensip geçerlidir: Kritik riski önce seç, control owner’ını belirle, coverage’ı ölç ve çalıştığını test et.

14. Siber güvenlik yatırımının ROI’si nasıl gösterilir?

Siber güvenlik geliri doğrudan artıran klasik bir yatırım gibi ölçülmeyebilir. Değeri çoğunlukla olay olasılığını azaltma, impact’i sınırlama, kesinti süresini kısaltma, uyum yükünü yönetme ve müşteri güvenini destekleme üzerinden ortaya çıkar.

“Kaç saldırı engelledik?” sorusu tek başına güvenilir değildir. Firewall’un blokladığı milyonlarca internet taraması büyük bir iş sonucu göstermeyebilir. Buna karşılık tek bir privileged access gap’inin kapanması önemli bir attack path’i ortadan kaldırabilir.

ROI’yi control sayısından risk senaryosuna taşımak

Ölçüm için önce somut scenario tanımlanmalıdır:

Ardından şu girdiler değerlendirilir:

• Scenario’nun mevcut yıllık gerçekleşme olasılığı
• Doğrudan finansal kayıp
• İş kesintisi ve recovery maliyeti
• Legal, privacy, müşteri ve itibar etkisi
• Mevcut control’lerin etkinliği
• Önerilen yatırımın olasılık veya etkiyi ne kadar değiştireceği
• Control’ün yıllık toplam maliyeti

Basitleştirilmiş bir modelde:

Yıllık risk azalması = Mevcut beklenen kayıp - Kontrol sonrası beklenen kayıp

ROSI = (Yıllık risk azalması - Yıllık kontrol maliyeti)
       / Yıllık kontrol maliyeti

Bu formül kesin gelecek tahmini üretmez. Özellikle düşük sıklıklı, yüksek etkili olaylarda olasılık aralığı kullanılmalı ve sonuç sensitivity analysis ile sunulmalıdır. Sahte hassasiyet, karar kalitesini artırmaz.

Örnek karar

Bir kurum Business Email Compromise için yılda 10 birim beklenen kayıp öngörüyor olsun. Phishing-resistant MFA, payment verification ve mailbox detection iyileştirmelerinin bu riski 3 birime düşürmesi, yıllık toplam control maliyetinin de 2 birim olması bekleniyorsa:

Yıllık risk azalması = 10 - 3 = 7 birim
ROSI = (7 - 2) / 2 = 2,5

Yani model, control maliyetinin üzerinde 2,5 kat net risk azaltma değeri öngörür. Bu yalnızca yöntemi göstermek için hipotetik bir örnektir. Gerçek karar kurumun loss data’sı, threat exposure’ı ve control effectiveness evidence’ıyla kurulmalıdır.

Yönetim panelinde hangi metric’ler bulunmalı?

Metric, bir kararı değiştirmiyorsa dashboard süsüne dönüşebilir. Dengeli bir scorecard şu grupları birlikte izler:

Exposure metric’leri

• Internet-facing sahipsiz asset sayısı
• Critical ve actively exploited finding’lerin exposure süresi
• Privileged account içinde phishing-resistant MFA coverage’ı
• EDR, vulnerability scan ve critical log coverage’ı

Control effectiveness metric’leri

• Purple/Red Team testinde görülen ve görülmeyen technique oranı
• Restore test başarı oranı ve gerçekleşen RTO/RPO
• Pentest bulgularında retest ile doğrulanan kapanış
• Detection testlerinde expected alert ve playbook başarısı

Response metric’leri

• Mean Time to Detect
• Mean Time to Contain
• High-severity incident escalation süresi
• Evidence eksikliği nedeniyle sonuçlandırılamayan incident oranı

Program metric’leri

• Süresi dolmuş risk exception’ları
• Tekrarlayan root cause
• Kritik supplier assessment coverage’ı
• Security action plan’ında overdue risk sayısı

Bulgu sayısının düşmesi her zaman iyileşme değildir. Scope küçülmüş veya detection bozulmuş olabilir. Bu nedenle sayıların yanında coverage ve veri kalitesi gösterilmelidir.

15. 0-3-6-12 aylık kurumsal siber güvenlik yol haritası

Her kurumun roadmap’i farklıdır. Aşağıdaki plan, başlangıç veya orta seviyedeki bir kurum için referans sıralama sunar. Regüle sektör, OT environment, yüksek riskli ödeme akışı veya aktif incident gibi koşullar önceliği değiştirebilir.

Yol haritası

İlk 30 günde neden her şey çözülmeye çalışılmıyor?

Çünkü hızlı ve kontrolsüz değişiklik production kesintisi yaratabilir. İlk ayın hedefi bütün security backlog’unu bitirmek değil, kritik hizmeti ve en tehlikeli exposure’ı görmek, acil riskleri düşürmek ve sonraki kararlar için owner oluşturmaktır.

Örneğin bütün admin yetkilerini tek gecede kaldırmak operasyonu durdurabilir. Önce active use, business owner, break-glass ve dependency incelenir. Buna karşılık internete açık unutulmuş management interface veya default credential gibi açık riskler hızlı containment gerektirebilir.

3-6 ay arasında ofansif test neden devreye giriyor?

Temel inventory ve owner’lar oluşmadan bulunan bulgular doğru ekibe ulaşmayabilir. En azından kritik kapsam ve remediation akışı kurulunca sızma testi, kaynak kod analizi ve diğer assessment’lar daha kalıcı sonuç üretir.

Bu bir “ilk altı ay test yapılmaz” kuralı değildir. Yeni release, müşteri yükümlülüğü veya yüksek riskli exposure varsa test daha erken yapılmalıdır. Doğru zamanlamayı Sızma Testi Ne Zaman Yaptırılmalı? yazısında release ve incident senaryolarıyla ele aldık.

Red Team yol haritasının neden sonlarına yakın?

Red Team, detection ve response capability’si ölçülebildiğinde daha çok değer üretir. SOC’un hangi log’u izleyeceği, alert’i kimin sahiplenip containment uygulayacağı belli değilse sonuç zaten bilinen temel boşluklara dönebilir.

Hazır olmayan kurum için white-box pentest, assumed breach, Purple Team veya targeted detection validation daha ekonomik bir ara adım olabilir.

16. Doğru siber güvenlik iş ortağı seçerken 10 kriter

Siber güvenlik hizmeti alırken en uzun tool listesine veya en düşük gün fiyatına göre seçim yapmak kapsam ve sonuç kalitesini zayıflatabilir. İş ortağı, kurumun yerine risk sahibi olmaz. Fakat doğru soruları sorar, teknik kanıt üretir ve ekibin uygulanabilir karar almasını kolaylaştırır.

1. Scope’u iş hedefinden mi, hazır paket listesinden mi çıkarıyor?

İyi sağlayıcı önce kritik hizmeti, threat scenario’yu, technology stack’i ve beklenen çıktıyı anlamaya çalışır. “Kaç IP var?” gerekli bir sorudur, fakat tek başına scope belirlemez.

2. Kullanacağı yöntemin sınırlarını açıkça anlatıyor mu?

Zafiyet taramanın pentest yerine, pentest’in Red Team yerine veya SAST’ın Secure Code Review yerine satılması yanlış beklenti oluşturur. Sağlayıcı hangi yöntemin neyi göstereceğini ve neyi göstermeyeceğini açıkça belirtmelidir.

3. Uzman yetkinlikleri çalışmanın türüyle eşleşiyor mu?

Sertifika tek başına kalite garantisi değildir. Yine de uygulamalı yetkinlik, deneyim ve specialization için doğrulanabilir sinyal sağlar. Network pentest, web exploitation, source code review, cloud ve Red Team aynı uzmanlık alanı değildir.

OSCP ve OSWE gibi sertifikalar bireysel uzman yetkinliğidir. Kurumun kendisine aitmiş gibi sunulmamalıdır. SECNODEX çalışmalarında ilgili kapsam, OSCP, OSWE ve ilgili TSE personel sertifikalarına sahip uzmanların deneyimiyle eşleştirilir.

4. Otomasyonu uzman analizinden ayırıyor mu?

Scanner, coverage ve tekrar sağlar. Uzman ise false positive’i, exploitability’yi, business logic’i ve chained attack path’i değerlendirir. Tek tuşla üretilen rapor, manuel değerlendirme olarak pazarlanmamalıdır.

5. Rules of Engagement ve güvenli çalışma koşulları açık mı?

Yetkilendirme, test window’u, test hesapları, yasaklı aksiyonlar, data handling, emergency contact, source IP ve durdurma koşulları sözleşme öncesinde belirlenmelidir.

6. Rapor farklı okuyuculara uygun mu?

Yönetici özeti business impact ve önceliği anlatmalıdır. Teknik finding ise affected asset, precondition, evidence, PoC, root cause, remediation ve doğrulama adımını içermelidir. Yalnızca CVSS ve generic açıklama geliştirme ekibine yetmez.

7. Remediation desteği ve retest var mı?

Finding’in açıklanması, çözüm alternatiflerinin tartışılması ve düzeltmenin güvenli şekilde kapandığının retest ile doğrulanması çalışma modeline dahil olmalıdır. “Ticket kapandı” teknik doğrulama değildir.

8. Veri güvenliği nasıl sağlanıyor?

NDA tek başına yeterli değildir. Test sırasında görülen source code, credential, PoC, customer data ve log’ların:

• Nerede tutulduğu
• Kimlerin erişebildiği
• Nasıl şifrelendiği
• Ne kadar süre saklandığı
• Subprocessor ile paylaşılıp paylaşılmadığı
• Nasıl güvenli silindiği

açık olmalıdır.

9. Bulguyu kurumun mevcut sürecine aktarabiliyor mu?

Rapor tesliminden sonra bulguların Jira, ticketing veya GRC sistemine aktarılması, owner ve deadline ile eşleşmesi, duplicate ve exception yönetimi işin sürdürülebilirliğini artırır.

10. Başarı ölçütü sözleşmede tanımlı mı?

Çalışmanın başarısı “kritik açık bulmak” olamaz. Gerçekte kritik açık olmayabilir. Başarı, onaylı scope’un metodolojiye uygun değerlendirilmesi, evidence kalitesi, test coverage’ı, güvenli yürütme, anlaşılır raporlama ve remediation’a dönüşen çıktı üzerinden ölçülmelidir.

SECNODEX’in ofansif ve danışmanlık çalışmalarını bir arada görmek için siber güvenlik hizmetleri sayfasını inceleyebilir, kurumunuzun mevcut durumu ve hedefleri için Siber Güvenlik Danışmanlığı kapsamında bir yol haritası oluşturabilirsiniz.

18. Sonuç: Güvenlik, kontrol sahibi olmak değil kontrolün çalıştığını bilmektir

Kurumsal siber güvenlik tek bir ürünle, denetim dönemiyle veya yılda bir yapılan testle tamamlanmaz. İş hizmetleri değişir. Yeni asset’ler açılır. Kullanıcı ve tedarikçi erişimleri büyür. Software her gün güncellenir. Threat actor’lar aynı zayıflıkları yeni attack chain’ler içinde kullanır.

Bu değişim karşısında dayanıklı kurumlar mükemmel oldukları için değil, risklerini görünür ve yönetilebilir tuttukları için daha hızlı hareket eder. Kritik hizmeti ve owner’ını bilir. Preventive control başarısız olduğunda detection’ın devreye girip girmediğini test eder. Incident sırasında yetki tartışmaz. Backup’ın yalnızca varlığına değil, geri dönüş kanıtına bakar. Bulguyu kapatmakla yetinmez, root cause’un tekrarını önler.

Sağlam bir program şu bütünlüğü kurar:

1. 1Yönetimin sahip olduğu cyber risk governance
2. 2Güncel asset, identity, data ve third-party görünürlüğü
3. 3Identity-first ve Defense in Depth architecture
4. 4Sürekli zafiyet yönetimi ve Secure SDLC
5. 5Sızma testi, Secure Code Review ve gerektiğinde Red Team ile teknik doğrulama
6. 6SOC, SIEM, EDR/MDR ve test edilmiş detection capability’si
7. 7Hazırlanmış Incident Response ve gerçekten çalıştırılmış recovery planı
8. 8İş etkisine bağlanan metric, roadmap ve yatırım kararı

SECNODEX, kurumsal güvenlik çalışmalarını hazır bir ürün listesine göre değil, kurumun attack surface’i, iş hedefleri ve mevcut maturity’si üzerinden planlar. Sızma Testi, Red Team, Zafiyet Tarama, Kaynak Kod Analizi ve danışmanlık çalışmalarından gelen teknik kanıtı uygulanabilir remediation ve yol haritasına dönüştürür.

Mevcut durumunuzu değerlendirmek, ilk 90 günlük öncelikleri belirlemek veya dağınık güvenlik çalışmalarını ölçülebilir bir programa çevirmek için SECNODEX ile iletişime geçebilirsiniz.

Kaynaklar ve ileri okuma

• NIST — Cybersecurity Framework 2.0
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations
• NIST IR 8374 Rev. 1 — Ransomware Risk Management: A CSF 2.0 Community Profile
• NIST SP 800-207 — Zero Trust Architecture
• NIST SP 800-218 — Secure Software Development Framework 1.1
• ENISA — Threat Landscape 2025
• CISA — Known Exploited Vulnerabilities Catalog
• CISA — More than a Password: MFA Guidance
• ISO — ISO/IEC 27001:2022 Information Security Management Systems
• Kişisel Verileri Koruma Kurumu — Veri Güvenliğine İlişkin Yükümlülükler
• PCI Security Standards Council — PCI DSS v4.0.1

<!--

EDİTORYAL INTERNAL LINK NOTU

Bu şemsiye pillar aşağıdaki dört uzmanlık pillar'ının üst merkezidir:

1. 1/blog/sizma-testi-nedir-kapsamli-rehber
2. 2/blog/red-team-nedir-kapsamli-rehber
3. 3/blog/zafiyet-tarama-nedir-kapsamli-rehber
4. 4/blog/kaynak-kod-analizi-nedir-kapsamli-rehber

Öne çıkan destek cluster'ları:

• /blog/sizma-testi-ne-zaman-yaptirilmali
• /blog/her-kurumun-red-team-ihtiyaci-var-mi
• /blog/purple-team-red-team-bas-hangi-calisma-neyi-olcer
• /blog/idor-acigi-neden-hala-bu-kadar-yaygin

Her dört pillar'dan bu şemsiye sayfaya farklı ve doğal anchor text'lerle geri bağlantı kurulmalıdır.

Şemsiye sayfanın ana ticari bağlantısı /hizmetler/siber-guvenlik-danismanligi olmalıdır.

İkincil hizmet bağlantısı /hizmetler olmalıdır.

FAQPage schema yalnızca sayfada kullanıcıya görünür olan 12 soru-cevapla birebir eşleşecek biçimde eklenmelidir.

-->