Denetimden Geçmek Gerçekten Güvende Olmak mı?
Denetimden Geçmek Gerçekten Güvende Olmak mı?
Bankalar için denetim dönemleri geldiğinde, bankacılık sektöründe çalışanlar veya denetim ekiplerinde görev alanlar bilir; özellikle yıl sonu ayları oldukça yoğun geçer. Bir tarafta günlük işlerin yürütülmesi, diğer tarafta denetçilerin taleplerinin karşılanması derken iş yükü bir anda ciddi şekilde artar. Üstelik bu yoğunluk yalnızca bankalara özgü değil. Türkiye’de birçok şirket her yıl farklı kapsam ve standartlarda denetimlerden geçiyor; denetim kanıtları hazırlanıyor, tespit edilen bulgular için süreçler iyileştiriliyor, yeni kontroller tasarlanıyor, gerektiğinde yeni ürün veya teknolojiler satın alınıyor. Tüm bu çalışmaların sonunda denetimden bulgusuz çıkmak veya bir sertifikayı başarıyla almak elbette önemli bir başarı. Ancak burada kendimize sormamız gereken kritik bir soru var: Denetimden hiç bulgu almamak ya da bir sertifikaya sahip olmak, artık “çok güvenliyiz, her şeyimiz tamam” demek için yeterli mi?
Bir kurumun ISO 27001 sertifikasına sahip olması, PCI DSS gereksinimlerini karşılaması, düzenleyici denetimlerden başarıyla geçmesi veya kapsamlı güvenlik ürünlerine yatırım yapması önemli güvenlik göstergeleridir ancak bunların hiçbiri tek başına kurumun güvenli olduğu anlamına gelmez. Uyumluluk ile güvenlik aynı şeyi ölçmez. Uyumluluk çoğunlukla belirlenmiş gereksinimlerin, politikaların ve kontrollerin mevcut olduğunu ve belirli kriterlere göre işletildiğini göstermeye çalışır. Güvenlik ise çok daha dinamik bir soruya cevap arar: “Kurum bugün gerçekten ne kadar savunulabilir durumda?” Bu iki soru birbirine yakın görünse de aralarında önemli bir fark vardır.
Kontrolün var olması, kontrolün etkili olduğu anlamına gelmez
Denetimler genellikle belirli kapsamlar ve örneklem üzerinden gerçekleştirilir. Bu kapsamlar, kurumun yapısına ve denetimin amacına göre değişebilse de bazı kontrol alanları yıllar içerisinde benzer şekilde tekrar tekrar incelenebilir. Ancak bir kontrolün denetim kapsamında yer alması veya denetimden başarıyla geçmesi, kapsam dışında kalan alanların da aynı güvenlik seviyesinde olduğu anlamına gelmez.
Örneğin, 10.000 endpoint bulunan bir kurumda EDR çözümünün %99 oranında kurulu olması ilk bakışta oldukça başarılı bir sonuç gibi görünebilir. Ancak kapsam dışında kalan 100 cihazın kritik sunucular veya yönetici bilgisayarları olduğunu düşünelim. Bu durumda %99’luk kapsama oranı, kurumun gerçek güvenlik seviyesini düşündüğümüzden çok daha farklı bir noktaya taşıyabilir. Benzer durum zafiyet yönetimi için de geçerlidir. “Düzenli zafiyet taraması yapılıyor mu?” sorusunun cevabı evet olabilir. Ancak güvenlik açısından asıl değerlendirilmesi gereken sorular şunlardır:
- Kritik varlıkların yüzde kaçı düzenli olarak taranıyor?
- İnternete açık varlıkların tamamı keşfedilmiş mi?
- Kritik ve yüksek seviyeli zafiyetlerin ortalama kapanma süresi ne kadar?
- SLA dışına çıkan zafiyetlerin oranı nedir?
- Bilinen zafiyetlerden hangileri aktif olarak istismar ediliyor?
- Aynı zafiyetler tekrar tekrar ortaya çıkıyor mu?
- Zafiyet bulunan varlıkların iş kritiklikleri doğru şekilde sınıflandırılmış mı?
Buradaki temel fark aslında oldukça basit: “Tarama yapıyoruz” bir faaliyet göstergesidir.
“Maruziyetimizi azaltıyoruz” ise bir güvenlik göstergesidir. Güvenlik açısından önemli olan yalnızca bir kontrolün uygulanıyor olması değil, o kontrolün doğru varlıkları kapsaması, etkili çalışması ve kurumun gerçek riskini azaltmasıdır.
Denetim anlık fotoğrafı, güvenlik ise canlı sistemi gösterir
Siber güvenliğin en önemli problemlerinden biri, kurumun güvenlik durumunun sürekli değişmesidir. Yeni bir sunucunun devreye alınması, bir SaaS uygulamasının kullanılmaya başlanması, tedarikçiye VPN erişimi verilmesi, bir kullanıcıya geçici administrator yetkisi tanımlanması, yeni bir firewall kuralının açılması, bir API’nin internete açılması, güvenlik ajanının devre dışı kalması veya bulut ortamında yanlış bir yapılandırmanın oluşması kurumun saldırı yüzeyini ve güvenlik seviyesini doğrudan değiştirebilir. Ancak sertifikasyon ve periyodik denetimler, bu değişikliklerin tamamını anlık olarak tespit edemez. Bu nedenle denetimler çoğu zaman kurumun güvenlik durumunun belirli bir andaki fotoğrafını gösterirken, siber güvenlik sürekli değişen bir video gibidir. Bugün tüm güvenlik kontrolleri doğru şekilde çalışıyor olsa bile, yarın yapılacak küçük bir değişiklik saldırı yüzeyini önemli ölçüde değiştirebilir. Bu nedenle kurumların güvenlik programlarını yalnızca “denetimden geçme” hedefi üzerine değil, değişiklikleri ve güvenlik kontrollerinin etkinliğini sürekli izleyen “Sürekli Güvenlik Doğrulaması” yaklaşımı üzerine kurması gerekmektedir.
Kontrolün varlığından daha önemlisi kontrolün çalışmasıdır
Olgun güvenlik ekiplerinde bakış açısı, güvenlik kontrolünün yalnızca var olup olmadığını sorgulamaktan çıkıp gerçekten ne kadar etkili çalıştığını ölçmeye doğru değişir. Örneğin bir kurumda MFA politikası uygulanıyor olabilir ancak MFA kapsamının ne kadar olduğu, hangi hesapların kapsam dışında kaldığı, legacy authentication kullanımının devam edip etmediği, servis hesaplarının nasıl korunduğu, Conditional Access istisnalarının bulunup bulunmadığı, ayrıcalıklı hesaplarda phishing-resistant authentication kullanılıp kullanılmadığı ve olası MFA bypass senaryolarının test edilip edilmediği bilinmeden gerçek güvenlik seviyesini ölçmek mümkün değildir. Aynı yaklaşım SIEM çözümleri için de geçerlidir. Bir SIEM ürününün kurulu olması tek başına yeterli değildir; önemli olan hangi varlıklardan log topladığı, hangi tehdit ve olayları tespit edebildiği, hangi korelasyon kurallarının aktif olduğu, üretilen alarmların kalitesi ve SOC ekiplerinin bu alarmlara ne kadar hızlı müdahale edebildiğidir. Bir kurum milyonlarca log topluyor olabilir, ancak saldırganın gerçekleştirdiği kritik bir hareket mevcut korelasyon ve tespit mekanizmaları tarafından yakalanamıyorsa yüksek log hacmi tek başına yüksek güvenlik seviyesi anlamına gelmez.
Güvenlik ürünlerinin sayısı da güvenlik seviyesi değildir
Kurumsal yapılarda zaman içerisinde ciddi bir security tool sprawl oluşabiliyor. EDR, NDR, SIEM, SOAR, DLP, PAM, IAM, WAF, CSPM, CNAPP, ASM, zafiuyet yönetimi, e-mail güvenliği, sandbox, UEBA ve daha birçok çözüm aynı ortamda bulunabiliyor. Ancak ürün sayısının artması otomatik olarak güvenlik seviyesinin artması anlamına gelmez. Tam tersine bazı durumlarda yeni riskler ortaya çıkabilir. Örneğin; Bir EDR agent’ı başka bir güvenlik agent’ı ile çakışabilir. Bir güvenlik ürününün privileged service account’u gereğinden fazla yetkiye sahip olabilir. Bir SaaS güvenlik platformuna kurumun hassas logları gönderilebilir. Bir güvenlik ürününün yönetim konsoluna fazla sayıda kullanıcı erişebilir. Ürünlerin API anahtarları uzun süre değiştirilmeden kullanılabilir. Bir ürün devre dışı kaldığında bunu tespit edecek bir kontrol bulunmayabilir. Bu nedenle CISO açısından önemli metriklerden biri yalnızca tool coverage değil, security control effectiveness olmalıdır.
Backup alıyoruz demek, kurtulabiliriz demek değildir
Backup bunun en klasik örneklerinden biridir. Bir denetimde: “Backup alıyor musunuz?” sorusunun cevabı “Evet” olabilir. Ancak güvenlik bakış açısından sorulması gereken sorular:
- Backup’lar değiştirilemez mi?
- Production ortamından ayrıştırılmış mı?
- Backup hesapları ayrı kimliklerle korunuyor mu?
- Backup yönetim konsoluna MFA uygulanıyor mu?
- Ransomware saldırısında backup altyapısı da etkilenebilir mi?
- Son restore testi ne zaman yapıldı?
- Gerçek bir sistem ne kadar sürede restore edilebiliyor?
- RPO ve RTO gerçekten karşılanabiliyor mu?
- Backup bütünlüğü doğrulanıyor mu?
Başka bir ifadeyle: Backup almak bir kontroldür. Restore edebilmek ise güvenlik kabiliyetidir.
IAM tarafında da aynı problem var
Bir kurumda IAM sistemi bulunabilir, access request süreçleri uygulanabilir ve periyodik access review çalışmaları düzenli olarak gerçekleştirilebilir. Ancak bu süreçlerin varlığı tek başına erişim risklerinin gerçekten azaltıldığı anlamına gelmez. Örneğin bir çalışan departman değiştirdiğinde yeni rolü için gerekli yetkiler eklenirken eski yetkilerinin kaldırılmaması zaman içinde yetki yığılması oluşmasına neden olabilir. Benzer şekilde işten ayrılan bir çalışanın üçüncü taraf SaaS uygulamalarındaki hesaplarının aktif kalması, geçici olarak verilen administrator yetkisinin süresi dolduğunda otomatik olarak geri alınmaması veya artık kullanılmayan hesapların sistemlerde açık kalmaya devam etmesi önemli güvenlik riskleri oluşturur. Denetim açısından gerekli süreçler tanımlanmış ve tamamlanmış görünebilir; ancak güvenlik açısından asıl önemli olan, kullanıcının bugün fiilen hangi sistemlere ve hangi seviyede erişebildiğidir. Bu nedenle IAM olgunluğu değerlendirilirken yalnızca access review tamamlanma oranı gibi faaliyet metriklerine değil, excess privilege, orphaned accounts, dormant accounts, privilege escalation ve toxic combinations gibi doğrudan erişim riskini gösteren metriklere de odaklanılmalıdır.
Denetim metrikleri ile güvenlik metriklerini ayırmak gerekiyor
Güvenlik ekiplerinin en sık yaptığı hatalardan biri, faaliyet metriklerini doğrudan güvenlik metriği olarak değerlendirmektir. Örneğin “Ayda 10.000 zafiyet kapattık” ifadesi etkileyici görünebilir; ancak asıl sorulması gereken, kritik saldırı yüzeyinin ne ölçüde azaltıldığıdır. Benzer şekilde “100 adet phishing e-postası engelledik” demek tek başına yeterli değildir; önemli olan kaç saldırının kullanıcıya ulaştığı ve bu saldırıların ne kadarının başarıyla önlendiğidir. “10 milyon log topluyoruz” ifadesi de ancak gerçek saldırıların ne kadarının tespit edilebildiğiyle birlikte anlam kazanır. Aynı şekilde çalışanların %98’inin güvenlik farkındalık eğitimini tamamlamış olması olumlu bir faaliyet göstergesi olsa da gerçek güvenlik seviyesini göstermek için phishing simülasyonlarındaki başarı oranı ve kullanıcı davranışındaki değişim de ölçülmelidir. Bu nedenle CISO dashboard’larında yalnızca yapılan faaliyetleri değil, bu faaliyetlerin risk azaltımına ve gerçek güvenlik seviyesine olan etkisini gösteren metriklere yer verilmesi kritik önem taşır.
Faaliyet metriği ≠ Güvenlik metriği
|
Faaliyet |
Daha anlamlı güvenlik göstergesi |
|
Vulnerability scan sayısı |
Kritik exposure’ın kapanma oranı |
|
Kapatılan zafiyet sayısı |
Risk bazlı iyileştirme etkisi |
|
EDR kurulum oranı |
Kritik varlıklarda gerçek-time EDR coverage |
|
Toplanan log miktarı |
Detection coverage ve MTTD |
|
Açılan/kapatılan ticket sayısı |
Risk azaltma etkisi |
|
MFA kullanım oranı |
Riskli hesapların phishing-resistant MFA kapsamı |
|
Erişim gözden geçirme tamamlanma oranı |
Fazla yetki oranı |
|
Backup başarı oranı |
Başarılı restore testi ve RTO uyumu |
|
Güvenlik eğitiminin tamamlanması |
Oltalama simülasyonu başarısızlık oranı |
|
Penetration test sayısı |
Tespit edilen kritik bulguların kapanma süresi |
Peki denetimler gereksiz mi?
Tabiki hayır. Denetimler, standartlar ve regülasyonlar güvenlik programının önemli yapı taşlarıdır. ISO 27001, PCI DSS, DORA, BDDK gereksinimleri ve diğer güvenlik çerçeveleri kurumlara önemli bir kontrol tabanı sağlar. Problem, bunların güvenliğin tamamı olarak görülmesidir. Uyumluluk bize önemli bir temel sağlar. Fakat güvenlik ekiplerinin bunun üzerine sürekli çalışan bir katman oluşturması gerekir.
Bu güvenlik katmanı; kontrollerin sürekli izlenmesi, tehdit maruziyetinin sürekli yönetilmesi, saldırı yüzeyinin izlenmesi ve yönetilmesi, güvenlik kontrollerinin etkinliğinin doğrulanması, tehditlerin tespit edilmesi ve güvenlik olaylarına müdahale edilmesi gibi yeteneklerle desteklenebilir. Buradaki amaç yeni bir uyumluluk projesi oluşturmak değil, mevcut kontrollerin gerçekten çalıştığını sürekli doğrulamaktır.
CISO’ nun sorması gereken sorular değişmeli
Olgun güvenlik ekiplerinde bakış açısı, güvenlik kontrolünün yalnızca var olup olmadığını sorgulamaktan çıkıp gerçekten ne kadar etkili çalıştığını ölçmeye doğru değişir. Örneğin bir kurumda MFA politikası uygulanıyor olabilir; ancak MFA kapsamının ne kadar olduğu, hangi hesapların kapsam dışında kaldığı, legacy authentication kullanımının devam edip etmediği, servis hesaplarının nasıl korunduğu, Conditional Access istisnalarının bulunup bulunmadığı, ayrıcalıklı hesaplarda phishing-resistant authentication kullanılıp kullanılmadığı ve olası MFA bypass senaryolarının test edilip edilmediği bilinmeden gerçek güvenlik seviyesini ölçmek mümkün değildir. Aynı yaklaşım SIEM çözümleri için de geçerlidir. Bir SIEM ürününün kurulu olması tek başına yeterli değildir; önemli olan hangi varlıklardan log topladığı, hangi tehdit ve olayları tespit edebildiği, hangi korelasyon kurallarının aktif olduğu, üretilen alarmların kalitesi ve SOC ekiplerinin bu alarmlara ne kadar hızlı müdahale edebildiğidir. Bir kurum milyonlarca log topluyor olabilir, ancak saldırganın gerçekleştirdiği kritik bir hareket mevcut korelasyon ve tespit mekanizmaları tarafından yakalanamıyorsa yüksek log hacmi tek başına yüksek güvenlik seviyesi anlamına gelmez.
Sonuç: Uyumluluk bir hedef değil, tabandır
Güvenlik ve uyumluluk birbirinin alternatifi değildir. İyi tasarlanmış bir uyumluluk programı, güvenlik için gerekli minimum kontrol tabanını oluşturur. Bu tabanın üzerinde sürekli ölçüm, doğrulama, tehdit analizi ve iyileştirme mekanizmaları bulunmadığında kurum yalnızca kontrollere sahip olduğunu gösterebilir. Gerçek güvenlik ise başka bir sorunun cevabıdır: “Saldırı bugün gerçekleşirse, hangi kontrollerimiz gerçekten çalışacak?” Bu nedenle geleceğin güvenlik programlarında başarı kriteri yalnızca “denetimden geçtik” olmamalıdır.
Asıl başarı; kontrollerin kapsama oranını, etkinliğini, başarısızlıklarını, istisnalarını ve gerçek saldırı yüzeyindeki risk azaltma etkisini sürekli olarak görebilmektir. Çünkü denetim kurumun ne kadar uyumlu olduğunu gösterebilir. Yalnızca sürekli güvenlik doğrulaması, gerçekten ne kadar güvende olduğunuzu anlamanıza yardımcı olur. Uyumlu olmak bir sonuçtur. Güvenli olmak ise sürekli devam eden bir süreçtir.