Allah’ın Rahmeti Ve Bereketi Üzerinize Olsun
Selamun aleyküm dostlarım. Bu makalemizde Başlıca sızma testi çerçevelerinin amacını ve yapılan kavramlarını anlamaya çalışacağız. Çerçeveleri, kapsamları, metodolojileri ve amaçlanan kullanım durumları açısından karşılaştırmayı ve verilen etkileşim senaryosu için uygun bir çerçeve seçeceğiz bunuda tabi MITRE ATT&CK çerçevesinde yapacağız.
OSSTMM
Güvenlik ve Açık Metodolojiler Enstitüsü (ISECOM - Institute for Security and Open Methodologies) tarafından geliştirilen OSSTMM (şu anda 3. sürümündedir), güvenlik testine bilimsel yöntemi uygular. Temel özelliği “görüşler yerine metrikler” yaklaşımıdır: OSSTMM, öznel risk yorumları üretmek yerine ölçülebilir, doğrulanabilir ve tekrarlanabilir sonuçlar sunar.
OSSTMM, güvenliği yalnızca bir ağ problemi olarak görmeyip beş farklı güvenlik kanalı etrafında testleri organize eder:
OSSTMM’nin niceliksel yaklaşımının merkezinde Risk Değerlendirme Değerleri (RAV - Risk Assessment Values) yer alır. RAV, toplam saldırı yüzeyi (maruziyet) ile bu yüzeyi koruyan kontroller arasındaki dengeyi ölçer. Pozitif bir RAV, kalan riskin varlığını gösterir; sıfıra yakın bir RAV ise kontrollerin maruziyetle iyi dengelendiğini ifade eder. Bu sayısal çıktı sayesinde, aynı hedefi değerlendiren iki test uzmanı, tıpkı aynı kirişi ölçen iki mühendisin benzer sonuçlar elde etmesi gibi, karşılaştırılabilir sonuçlara ulaşabilir.
Bilimsel titizliği, OSSTMM’nin hem en güçlü yönü hem de en büyük engelidir. Bu çerçeve, sızma testi alanında nadir görülen bir şekilde sonuçları denetlenebilir ve karşılaştırılabilir hale getirir. Ancak öğrenme eğrisi oldukça diktir; tam kapsamlı uygulamaları zaman alabilir ve OSSTMM konusunda deneyimli uzman bulmak, OWASP veya NIST metodolojilerine göre daha zordur.
OSSTMM, özellikle tekrarlanabilir ve denetlenebilir güvenlik ölçümleri gerektiren ve bu metodolojiyi öğrenmeye yatırım yapmaya istekli olan kuruluşlar için en uygun yaklaşımdır.
OWASP WSTG
Çevrimiçi bir perakendeci için bir web uygulamasını test ediyorsunuz. Uygulama; kullanıcı kaydı, ürün arama, alışveriş sepeti, ödeme işlemleri ve sipariş takibi gibi işlevleri yerine getiriyor. Peki nereden başlamalısınız? İlk olarak giriş formunu mu test etmelisiniz? Arama çubuğunu mu? Ödeme API’sini mi? Tek bir web uygulamasında onlarca potansiyel saldırı yüzeyi bulunduğunda, aynı şeyleri iki kez test etmek veya bazı güvenlik açığı sınıflarını tamamen gözden kaçırmak oldukça kolaydır.
OWASP bu sorunu Web Security Testing Guide (WSTG) ile ele almaktadır. OWASP en çok kritik web güvenlik açıklarını listeleyen OWASP Top Ten ile tanınsa da, WSTG çok daha derine iner. Topluluk odaklı ve kapsamlı bir çerçeve olan WSTG, web uygulama testlerini on iki kategori altında gruplanmış 90’dan fazla ayrı test senaryosu hâlinde düzenler.
Bu on iki kategori, modern bir web uygulamasının tüm saldırı yüzeyini kapsar. Bunlar arasında bilgi toplama, yapılandırma ve dağıtım yönetimi, kimlik yönetimi, kimlik doğrulama, yetkilendirme, oturum yönetimi, girdi doğrulama, hata işleme, kriptografi, iş mantığı, istemci tarafı testleri ve API testleri yer alır. Her kategori, neyin test edileceğini ve nasıl test edileceğini adım adım açıklayan numaralandırılmış test senaryoları içerir (örneğin, yansıtılmış Cross-Site Scripting için WSTG-INPV-01).
WSTG, risk tabanlı bir yaklaşım benimser: güvenlik açıkları yalnızca kataloglanmaz, aynı zamanda istismar edilebilirlikleri ve etkilerine göre önceliklendirilir. Bu yaklaşım, test uzmanlarının çabalarını en önemli noktalara odaklamasına yardımcı olur.
Bunun nasıl çalıştığını, yeni bir müşteri portalı geliştiren ShopSecure Inc. adlı çevrimiçi perakende şirketi üzerinden inceleyelim.
Aşama 5: Bakım ve operasyon sırasında
Uygulama yayına alındıktan sonra güvenlik düzenli sağlık kontrolleriyle sürdürülür; özellikle güncellemelerden sonra bu süreç kritik hâle gelir. Örneğin ShopSecure, üç ay sonra yeni bir ürün öneri özelliği yayınladığında, ilgili WSTG test senaryoları yeniden çalıştırılarak güncellemenin yeni güvenlik açıkları oluşturmadığından emin olunur.
Bununla birlikte bazı dezavantajları da vardır. Tüm test senaryolarının eksiksiz uygulanması, kaynakları sınırlı ekipler için pratik olmayabilir. Bazı testler; kriptografik analiz veya iş mantığı testi gibi alanlarda özel uzmanlık gerektirir. Ayrıca test uzmanlarının yalnızca kontrol listesine bağlı kalıp testleri mekanik şekilde uygulaması ve uygulamanın genel risk durumunu değerlendirmeyi ihmal etmesi gibi bir risk de bulunmaktadır.
En başarılı uygulayıcılar, WSTG’yi bir temel olarak kullanırken aynı zamanda kontrol listesinin ötesine geçerek eleştirel düşünmeyi de sürece dahil ederler.
NIST SP 800-115
İşte bu ihtiyacı, NIST Special Publication 800-115 karşılar. ABD Ulusal Standartlar ve Teknoloji Enstitüsü NIST tarafından yayımlanan bu belge, bilgi sistemlerinin güvenlik durumunu sistematik biçimde değerlendirmek için temel bir çerçeve sunar. Her ne kadar ABD federal kurumları için geliştirilmiş olsa da, içerdiği prensipler geniş ölçüde uygulanabilir durumdadır ve özellikle yapılandırılmış ve tekrarlanabilir süreçlere önem veren özel sektör kuruluşları tarafından da yaygın şekilde benimsenmiştir.
NIST SP 800-115, dar anlamda yalnızca bir sızma testi çerçevesi değildir; çok daha geniş kapsamlıdır. Belge; doküman incelemeleri ve log analizlerinden güvenlik açığı taramalarına ve tam kapsamlı sızma testlerine kadar güvenlik testi ve değerlendirme tekniklerinin tamamını kapsar. Sızma testini, güvenlik kontrollerinin amaçlandığı şekilde çalışıp çalışmadığını doğrulamak için kullanılan birçok teknikten yalnızca biri olarak ele alır.
Bu çerçevenin üç temel amacı vardır:
Ayrıca iletişim protokolleri de tanımlanır:
NIST SP 800-115’in bu teknikleri pasiften aktife, düşük etkiden yüksek etkiye doğru ilerleyen bir süreç olarak ele aldığına dikkat edin. Her güvenlik değerlendirmesinin mutlaka tam kapsamlı sızma testine ulaşması gerekmez; bazı durumlarda yalnızca inceleme ve güvenlik açığı doğrulaması bile yeterli olabilir.
GovNet örneğinde:
Bununla birlikte bazı dezavantajları da vardır. NIST SP 800-115, denetim sıklıkları veya yaptırımlar konusunda zorunluluk getirmez. Örneğin PCI DSS yıllık sızma testlerini zorunlu tutarken, NIST SP 800-115 bir düzenleme değil, rehber niteliğindedir. Bu durum, özellikle yoğun şekilde regüle edilen sektörlerde tek başına yeterli bir uyumluluk aracı olarak kullanılmasını sınırlayabilir.
Ayrıca çerçeve, yetkin uzmanlar gerektirir. Çünkü metodoloji; doküman incelemesinden gerçek istismar (exploitation) faaliyetlerine kadar tüm tekniklerin uygulanabileceğini varsayar. Bu da test uzmanlarının geniş kapsamlı teknik bilgi ve deneyime sahip olmasını zorunlu kılar.
PTES
Birçok profesyonel sızma testi uzmanı için cevap, Penetration Testing Execution Standard (PTES) olurdu. PTES, deneyimli güvenlik uzmanlarından oluşan bir grup tarafından, “gerçek bir sızma testinin baştan sona nasıl yürütüldüğünü” tanımlamak amacıyla geliştirilmiştir. Diğer çerçeveler daha çok “neyin test edileceğine” veya “nasıl ölçüleceğine” odaklanırken, PTES bir sızma testi sürecinin başlangıçtan sona nasıl ilerlediğine odaklanır.
PTES, bir sızma testi çalışmasının yaşam döngüsünü doğrudan yansıtan yedi aşamadan oluşur. Bu yaklaşım özellikle yeni başlayan test uzmanları için oldukça pratiktir; çünkü birçok metodolojinin dolaylı bıraktığı şu soruya doğrudan cevap verir:
“İmzalanmış bir sözleşmem var; şimdi ilk gün, ikinci gün ve sonraki günlerde tam olarak ne yapacağım?”
Pasif keşif örnekleri:
MedGuard ortamında en değerli varlık hasta kayıt veritabanıdır. Tehdit modeli iki ana saldırı yolu ortaya koyar:
MedGuard örneğinde:
MedGuard ortamında:
Örnekler:
Örneğin:
Özellikle “ön etkileşim süreci” (pre-engagement interactions) konusundaki ayrıntılı yaklaşımı dikkat çekicidir. Birçok metodoloji kapsam belirleme ve yasal yetkilendirme süreçlerini yüzeysel geçerken, PTES bu konulara özel önem verir. Oysa deneyimsiz test uzmanlarının en maliyetli hataları genellikle tam da bu alanlarda ortaya çıkar.
Bununla birlikte bazı dezavantajları da vardır. PTES birkaç yıldır resmî olarak güncellenmemiştir ve teknik rehber bölümlerinde eski araçlar ile güncelliğini yitirmiş tekniklere referans verilmektedir. Metodolojinin temel yapısı ve aşamaları hâlâ güçlü olsa da, test uzmanlarının araç ve tekniklerle ilgili bölümleri güncel dokümantasyonlarla desteklemesi gerekir.
Ayrıca OSSTMM’de bulunan niceliksel metriklere sahip değildir. Bu nedenle sonuçlar, test uzmanının deneyimine ve kişisel değerlendirmesine daha fazla bağlıdır.
ISSAF
Genel Bakış
Hiç eski bir ders kitabını inceleyip, yaşına rağmen temel mantığının hâlâ geçerli olduğunu fark ettiniz mi? Siber güvenlikte araçlar ve exploitler kısa bir ömre sahiptir, ancak iyi tasarlanmış metodolojiler, test ettikleri teknolojilerden çok daha uzun süre dayanabilir. Bilgi Sistemleri Güvenlik Değerlendirme Çerçevesi (ISSAF - Information Systems Security Assessment Framework) bu duruma iyi bir örnektir.
Açık Bilgi Sistemleri Güvenliği Grubu (OISSG - Open Information Systems Security Group) tarafından geliştirilen ISSAF, ağ, sistem ve uygulama güvenliğini değerlendirmek için tasarlanmış açık kaynaklı bir sızma testi çerçevesidir. En son sürümü olan ISSAF v0.2.1 yaklaşık 2006 yılında yayımlanmıştır ve artık aktif olarak geliştirilmemektedir. Güncel bir resmî indirme kaynağı bulunmamaktadır; ancak taslak sürüm hâlâ arşivlenmiş kaynaklar üzerinden erişilebilir durumdadır. Bu önemli bir bağlamdır: ISSAF’in metodolojisi ve aşama yapısı öğretici olmaya devam etse de, araçlara özel teknik rehberi güncelliğini yitirmiştir ve güncel çalışmalar için güvenilir bir kaynak olarak kullanılmamalıdır.
Peki neden artık geliştirilmeyen bir çerçeveyi inceleyelim? Çünkü ISSAF’in dokuz adımlı değerlendirme modeli, bir saldırganın hedef bir sistem içinde nasıl ilerlediğini en net gösteren yapılardan biridir. Bu model, bir ileri düzey kalıcı tehdit (APT - Advanced Persistent Threat) mantığını taklit eder; başlangıç keşfinden kalıcı erişime ve izlerin silinmesine kadar sistematik bir ilerleyiş izler. Bu ilerleyiş size tanıdık geliyorsa, bunun nedeni daha önce bu modül içinde ayrıntılı olarak ele aldığınız Cyber Kill Chain yaklaşımıyla aynı mantığı paylaşmasıdır.Information Systems Security Assessment Framework (ISSAF); ağ altyapısı, sunucu sistemleri, web uygulamaları, veritabanları ve sosyal mühendislik gibi geniş bir güvenlik alanını kapsar. Risk tabanlı yaklaşımı sayesinde, düşük önem derecesine sahip bulgulardan ziyade yüksek etki yaratabilecek ve istismar edilebilir güvenlik açıklarına öncelik verir.
Bununla birlikte, güncellenmemiş olması önemli bir sınırlamadır. Araçlara özgü rehber bölümleri, günümüzden on yılı aşkın süre önceki yazılım sürümlerine atıfta bulunur ve bu dokümantasyonu güncelleyen aktif bir topluluk bulunmamaktadır. Bu nedenle ISSAF, teknik prosedürleri için değil, metodolojisi ve saldırgan mantığını anlamak için çalışılmalıdır.
Güncel araç ve teknikler için Penetration Testing Execution Standard (PTES), OWASP Web Security Testing Guide (WSTG) veya kullanılan araçların güncel dokümantasyonu gibi kaynaklarla desteklenmesi önerilir.
MITRE ATT&CK
Bu raporu alan müşteri ise basit ama kritik bir soru sorar: “Bizim saldırı yüzeyimiz, gerçek dünyada saldırganların yaptığı şeylerle ne kadar örtüşüyor?”
Bu soruya tek başına bir sızma testi çerçevesiyle net cevap vermek zordur. PTES ve OSSTMM gibi metodolojiler testin nasıl yapılacağını yapılandırır, ancak gerçek saldırganların hangi teknikleri kullandığını sistematik olarak sınıflandırmaz. İşte bu boşluğu dolduran yapı MITRE ATT&CK’tir.
ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge), MITRE Corporation tarafından geliştirilmiş ve sürdürülen bir bilgi tabanıdır. Geleneksel bir sızma testi çerçevesi değildir. Bunun yerine, gerçek dünyadaki tehdit aktörlerinin nasıl davrandığını gözlemleyerek oluşturulmuş bir saldırgan davranışları kataloğudur.
ATT&CK, saldırganların “ne yaptığını” sistematik bir şekilde sınıflandırır. Bu yapı, güvenlik uzmanlarının:
Bu tablonun sütunları taktikleri temsil eder. Taktikler, saldırganın üst düzey hedefleridir; yani “neden” bu işlemi yaptığıdır. Güncel Enterprise ATT&CK matrisi 14 taktik içerir ve şu ilerleyişi kapsar: ilk erişimden (initial access) başlayarak yürütme (execution), kalıcılık (persistence), yetki yükseltme (privilege escalation), savunma atlatma (defense evasion), kimlik bilgisi erişimi (credential access), keşif (discovery), yanal hareket (lateral movement), veri toplama (collection), komuta ve kontrol (command and control), veri sızdırma (exfiltration) ve etki (impact) aşamalarına kadar uzanır.
Her taktik sütununun altında ise teknikler (techniques) yer alır. Teknikler, saldırganın bir taktik hedefe ulaşmak için kullandığı spesifik yöntemlerdir; yani “nasıl” yapıldığını açıklar.
Örneğin Initial Access (İlk Erişim) taktiği altında şu teknikler bulunur:
Her teknik girdisi; açıklama, bu tekniği kullanan gerçek tehdit gruplarının örnekleri, tespit (detection) önerileri ve azaltma (mitigation) yöntemleri gibi bilgiler içerir. Bu da ATT&CK’i yalnızca bir sınıflandırma sistemi olmaktan çıkarır ve onu gözlemlenmiş saldırgan davranışlarına dayalı yaşayan bir referans haline getirir.
Bunun yerine, herhangi bir metodolojiyle (örneğin Penetration Testing Execution Standard (PTES)) gerçekleştirilen bir test sırasında ortaya çıkan bulguları ifade etmek için ortak bir dil sağlar.
Bunu anlamak için şu analoji oldukça açıklayıcıdır:
Bir PTES raporunu ATT&CK teknik kimlikleriyle açıklamak, test uzmanının MedGuard’ın güvenlik ekibine yalnızca bireysel zafiyetleri yamalamanın ötesinde, eyleme dönüştürülebilir içgörüler sağlamasına yardımcı olur. Müşteri artık her bir tekniği ATT&CK bilgi tabanında inceleyebilir, tespit rehberliğini gözden geçirebilir ve bu belirli davranışlara yönelik tespit kurallarını oluşturabilir veya doğrulayabilir. Böylece konuşma “şu tek hatayı düzeltelim” yaklaşımından “bu tür saldırgan davranışlarını tespit edebilir miyiz?” yaklaşımına dönüşür.
Kapanış Notları
ATT&CK’in gücü, saldırgan davranışlarını evrensel bir çevirmen gibi standartlaştırabilmesinde yatar. Bu sayede sızma testi uzmanları, tehdit istihbaratı analistleri, tespit mühendisleri ve olay müdahale ekipleri aynı dili konuşabilir. Özellikle sızma testi uzmanları için bulguları ATT&CK ile eşleştirmek, bir raporu yalnızca zafiyet listesinden çıkararak gerçek dünya tehdit davranışlarına dayanan bir anlatıya dönüştürür.
Bu bilgi tabanı oldukça kapsamlıdır ve ustalaşmak zaman gerektirir. Sadece Enterprise matrisi bile 200’den fazla teknik içerir. ATT&CK’i daha derin ve uygulamalı şekilde keşfetmek
Okuduğunuz için teşekkür ederim
Selamun aleyküm dostlarım. Bu makalemizde Başlıca sızma testi çerçevelerinin amacını ve yapılan kavramlarını anlamaya çalışacağız. Çerçeveleri, kapsamları, metodolojileri ve amaçlanan kullanım durumları açısından karşılaştırmayı ve verilen etkileşim senaryosu için uygun bir çerçeve seçeceğiz bunuda tabi MITRE ATT&CK çerçevesinde yapacağız.
OSSTMM
Genel Bakış
“Ölçemediğini yönetemezsin” ifadesini muhtemelen duymuşsundur. Çoğu mühendislik disiplininde niceliksel ölçüm standarttır: bir inşaat mühendisi bir köprünün “güvenli” olduğunu sezgiye dayanarak ilan etmez. Ancak sızma testlerinde (penetration testing) bulgular çoğu zaman öznel anlatılar şeklinde sunulur. Açık Kaynak Güvenlik Test Metodolojisi Kılavuzu (OSSTMM - Open Source Security Testing Methodology Manual) bu durumu değiştirmeyi amaçlar.Güvenlik ve Açık Metodolojiler Enstitüsü (ISECOM - Institute for Security and Open Methodologies) tarafından geliştirilen OSSTMM (şu anda 3. sürümündedir), güvenlik testine bilimsel yöntemi uygular. Temel özelliği “görüşler yerine metrikler” yaklaşımıdır: OSSTMM, öznel risk yorumları üretmek yerine ölçülebilir, doğrulanabilir ve tekrarlanabilir sonuçlar sunar.
OSSTMM, güvenliği yalnızca bir ağ problemi olarak görmeyip beş farklı güvenlik kanalı etrafında testleri organize eder:
- İnsan Güvenliği (HUMSEC - Human Security): Sosyal mühendislik ve insan faktöründen kaynaklanan zafiyetler.
- Fiziksel Güvenlik (PHYSSEC - Physical Security): Kartlı geçiş sistemlerinden yetkisiz giriş (tailgating) gibi fiziksel erişim kontrolleri.
- Kablosuz İletişim (SPECSEC - Wireless Communications): Wi-Fi, Bluetooth, RFID ve diğer elektromanyetik sinyaller.
- Telekomünikasyon (COMSEC - Telecommunications): Telefon sistemleri, VoIP, faks ve modem altyapısı.
- Veri Ağları (DATASEC - Data Networks): Ağ servisleri, güvenlik duvarları ve uygulama katmanı protokolleri.
OSSTMM’nin niceliksel yaklaşımının merkezinde Risk Değerlendirme Değerleri (RAV - Risk Assessment Values) yer alır. RAV, toplam saldırı yüzeyi (maruziyet) ile bu yüzeyi koruyan kontroller arasındaki dengeyi ölçer. Pozitif bir RAV, kalan riskin varlığını gösterir; sıfıra yakın bir RAV ise kontrollerin maruziyetle iyi dengelendiğini ifade eder. Bu sayısal çıktı sayesinde, aynı hedefi değerlendiren iki test uzmanı, tıpkı aynı kirişi ölçen iki mühendisin benzer sonuçlar elde etmesi gibi, karşılaştırılabilir sonuçlara ulaşabilir.
Aşamalar: Genel Bakış (Phases: A Walkthrough)
OSSTMM test döngüsü dört aşamadan oluşur. Bunu bir senaryo üzerinden inceleyelim: ekibiniz, FinVault Corp adlı bir finansal hizmet şirketinin dış ağını değerlendiriyor. Kapsam 10.0.113.0/24 ağı ve portal.finvault-corp.thm müşteri portalıdır.Aşama 1: Induction (Gözlemleme ve Doğrulama)
Induction aşaması, keşif (enumeration) ve doğrulamayı kapsar. Burada amaç, var olan varlıkları haritalamak ve gerçekten mevcut olduklarını doğrulamaktır. FinVault örneğinde DNS sorguları yapılır, certificate transparency logları incelenir ve vpn.finvault-corp.thm ile mail.finvault-corp.thm gibi alt alan adları keşfedilir. Daha sonra her bir varlık test edilerek aktif ve yanıt verir durumda olduğu doğrulanır. Çıktı, hedef ortamın doğrulanmış bir envanteridir.Aşama 2: Interaction (Etkileşim)
Interaction aşaması, niteliklendirme ve niceliklendirmeyi içerir. Bu aşamada doğrulanmış varlıklara aktif olarak etkileşim kurulur ve bunların önemi değerlendirilir. FinVault örneğinde her servise bağlanılır, kullanılan teknoloji belirlenir (fingerprinting) ve maruziyet ölçülür: 8 host üzerinde 12 dışa açık servis bulunur ve bunların 4’ü kimlik doğrulamasız erişim kabul eder. Bu bulgular doğrudan saldırı yüzeyi hesaplamasına katkı sağlar.Aşama 3: Inquiry (Sorgulama)
Inquiry aşaması, yetki yükseltme ve doğrulama genişletmesini kapsar. Bu aşamada ölçülen maruziyetin yetkisiz erişime dönüştürülüp dönüştürülemeyeceği test edilir. FinVault senaryosunda müşteri portalında bir IDOR (Insecure Direct Object Reference) zafiyeti keşfedilir ve bu açık sayesinde bir kullanıcının başka bir müşterinin hesap dökümlerini okuyabildiği tespit edilir. Doğrulama genişletmesi, etkinin kapsamını netleştirir: 12.000 hesaba salt-okuma erişimi vardır, yazma yetkisi yoktur.Aşama 4: Intervention (Müdahale)
Intervention aşaması; karantinaya alma, denetim ve aldatma (enticement) süreçlerini kapsar. Bu aşamada bulgular ele alınır ve daha geniş kontrol ortamı incelenir. FinVault örneğinde, zafiyetli uç nokta kısıtlanır ve aynı zamanda bir yama geliştirilir (quarantine). Erişim kontrol modeli benzer hatalar açısından incelenir (audit) ve iç tespit yeteneklerini test etmek için bir “canary token” yerleştirilir (enticement).Kapanış Notları (Closing Notes)
OSSTMM, çıktıların hazırlanmasında Security Test Audit Report (STAR) formatını zorunlu kılar. Bu yaklaşım, raporlamada tutarlılığı sağlar ve farklı ekipler arasında karşılaştırılabilirliği mümkün hale getirir.Bilimsel titizliği, OSSTMM’nin hem en güçlü yönü hem de en büyük engelidir. Bu çerçeve, sızma testi alanında nadir görülen bir şekilde sonuçları denetlenebilir ve karşılaştırılabilir hale getirir. Ancak öğrenme eğrisi oldukça diktir; tam kapsamlı uygulamaları zaman alabilir ve OSSTMM konusunda deneyimli uzman bulmak, OWASP veya NIST metodolojilerine göre daha zordur.
OSSTMM, özellikle tekrarlanabilir ve denetlenebilir güvenlik ölçümleri gerektiren ve bu metodolojiyi öğrenmeye yatırım yapmaya istekli olan kuruluşlar için en uygun yaklaşımdır.
OWASP WSTG
Çevrimiçi bir perakendeci için bir web uygulamasını test ediyorsunuz. Uygulama; kullanıcı kaydı, ürün arama, alışveriş sepeti, ödeme işlemleri ve sipariş takibi gibi işlevleri yerine getiriyor. Peki nereden başlamalısınız? İlk olarak giriş formunu mu test etmelisiniz? Arama çubuğunu mu? Ödeme API’sini mi? Tek bir web uygulamasında onlarca potansiyel saldırı yüzeyi bulunduğunda, aynı şeyleri iki kez test etmek veya bazı güvenlik açığı sınıflarını tamamen gözden kaçırmak oldukça kolaydır.
OWASP bu sorunu Web Security Testing Guide (WSTG) ile ele almaktadır. OWASP en çok kritik web güvenlik açıklarını listeleyen OWASP Top Ten ile tanınsa da, WSTG çok daha derine iner. Topluluk odaklı ve kapsamlı bir çerçeve olan WSTG, web uygulama testlerini on iki kategori altında gruplanmış 90’dan fazla ayrı test senaryosu hâlinde düzenler.
Bu on iki kategori, modern bir web uygulamasının tüm saldırı yüzeyini kapsar. Bunlar arasında bilgi toplama, yapılandırma ve dağıtım yönetimi, kimlik yönetimi, kimlik doğrulama, yetkilendirme, oturum yönetimi, girdi doğrulama, hata işleme, kriptografi, iş mantığı, istemci tarafı testleri ve API testleri yer alır. Her kategori, neyin test edileceğini ve nasıl test edileceğini adım adım açıklayan numaralandırılmış test senaryoları içerir (örneğin, yansıtılmış Cross-Site Scripting için WSTG-INPV-01).
WSTG, risk tabanlı bir yaklaşım benimser: güvenlik açıkları yalnızca kataloglanmaz, aynı zamanda istismar edilebilirlikleri ve etkilerine göre önceliklendirilir. Bu yaklaşım, test uzmanlarının çabalarını en önemli noktalara odaklamasına yardımcı olur.
Aşamalar: SDLC Boyunca Güvenlik
Web Security Testing Guide (WSTG)’yi birçok sızma testi çerçevesinden ayıran en önemli özelliklerden biri, güvenliği tek seferlik bir olay olarak görmemesidir. Bunun yerine WSTG, test süreçlerini Yazılım Geliştirme Yaşam Döngüsü (SDLC - Software Development Life Cycle) boyunca beş aşamaya yayarak güvenliği ilk planlamadan lansman sonrası bakıma kadar sürecin içine entegre eder.Bunun nasıl çalıştığını, yeni bir müşteri portalı geliştiren ShopSecure Inc. adlı çevrimiçi perakende şirketi üzerinden inceleyelim.
Aşama 1: Geliştirme başlamadan önce
Güvenlik gereksinimleri ve yasal yükümlülükler en baştan belirlenir. ShopSecure için bu, portalın ödeme işlemleri gerçekleştirdiği için PCI DSS standartlarına uyumlu olması gerektiğinin tanımlanması anlamına gelir. Ayrıca güvenlik açıklarının yamalanması için kabul edilebilir maksimum süre gibi ölçülebilir kriterler de belirlenir.Aşama 2: Tanımlama ve tasarım sırasında
Herhangi bir kod yazılmadan önce uygulama mimarisi güvenlik açıkları açısından incelenir. ShopSecure ekibi, ödeme akışı için tehdit modelleri oluşturur ve ödeme API’sinin yüksek değerli bir hedef olacağını belirler. Bunun sonucunda oran sınırlama (rate limiting) ve girdi doğrulama (input validation) kontrolleri daha tasarım aşamasında planlanır.Aşama 3: Geliştirme sırasında
Kod, incelemeler ve gözden geçirmeler yoluyla değerlendirilir. ShopSecure geliştiricileri, kimlik doğrulama modülünü kimlik bilgisi yönetimiyle ilgili WSTG-ATHN test senaryolarına göre inceler ve parola sıfırlama belirteçlerinin (password reset tokens) süresinin dolmaması gibi bir güvenlik açığını tespit eder.Aşama 4: Dağıtım sırasında
Üretim ortamındaki güvenlik kontrolleri doğrulanır. ShopSecure ekibi, hazırlık ortamındaki uygulama üzerinde bir sızma testi gerçekleştirir; varsayılan kimlik bilgilerinin değiştirildiğini, TLS yapılandırmasının doğru olduğunu ve hata ayıklama (debug) uç noktalarının açık olmadığını doğrular.Aşama 5: Bakım ve operasyon sırasında
Uygulama yayına alındıktan sonra güvenlik düzenli sağlık kontrolleriyle sürdürülür; özellikle güncellemelerden sonra bu süreç kritik hâle gelir. Örneğin ShopSecure, üç ay sonra yeni bir ürün öneri özelliği yayınladığında, ilgili WSTG test senaryoları yeniden çalıştırılarak güncellemenin yeni güvenlik açıkları oluşturmadığından emin olunur.
Kapanış Notları
Web Security Testing Guide (WSTG)’nin en büyük gücü, kapsamlı ve pratik yaklaşımıdır. 90’dan fazla test senaryosu içeren bu rehber, her senaryo için belirli prosedürler ve beklenen sonuçlar sunarak test uzmanlarına soyut prensipler yerine somut bir yol haritası sağlar. Ayrıca, dünya çapındaki güvenlik profesyonellerinden oluşan topluluk tarafından sürekli güncellenmesi sayesinde yeni güvenlik açığı türleri ve SPA (Single Page Application) ile mikroservis mimarileri gibi modern yapılarla güncel kalmayı başarır.Bununla birlikte bazı dezavantajları da vardır. Tüm test senaryolarının eksiksiz uygulanması, kaynakları sınırlı ekipler için pratik olmayabilir. Bazı testler; kriptografik analiz veya iş mantığı testi gibi alanlarda özel uzmanlık gerektirir. Ayrıca test uzmanlarının yalnızca kontrol listesine bağlı kalıp testleri mekanik şekilde uygulaması ve uygulamanın genel risk durumunu değerlendirmeyi ihmal etmesi gibi bir risk de bulunmaktadır.
En başarılı uygulayıcılar, WSTG’yi bir temel olarak kullanırken aynı zamanda kontrol listesinin ötesine geçerek eleştirel düşünmeyi de sürece dahil ederler.
NIST SP 800-115
Genel Bakış
Şu senaryoyu düşünün: Federal hükümetle çalışan bir devlet kurumunda veya büyük bir şirkette güvenlik analisti olarak çalışıyorsunuz. Kuruluşunuzun bir güvenlik değerlendirmesine ihtiyacı var; ancak elde edilecek sonuçların denetçileri tatmin etmesi, federal yönergelere uygun olması ve olası incelemelerde savunulabilir nitelikte olması gerekiyor. Gayriresmî yorumlar ve öznel risk değerlendirmeleriyle dolu bir sızma testi raporu bu durumda yeterli olmayacaktır. Federal düzenleyicilerin tanıdığı ve güvendiği bir metodolojiye ihtiyaç duyarsınız.İşte bu ihtiyacı, NIST Special Publication 800-115 karşılar. ABD Ulusal Standartlar ve Teknoloji Enstitüsü NIST tarafından yayımlanan bu belge, bilgi sistemlerinin güvenlik durumunu sistematik biçimde değerlendirmek için temel bir çerçeve sunar. Her ne kadar ABD federal kurumları için geliştirilmiş olsa da, içerdiği prensipler geniş ölçüde uygulanabilir durumdadır ve özellikle yapılandırılmış ve tekrarlanabilir süreçlere önem veren özel sektör kuruluşları tarafından da yaygın şekilde benimsenmiştir.
NIST SP 800-115, dar anlamda yalnızca bir sızma testi çerçevesi değildir; çok daha geniş kapsamlıdır. Belge; doküman incelemeleri ve log analizlerinden güvenlik açığı taramalarına ve tam kapsamlı sızma testlerine kadar güvenlik testi ve değerlendirme tekniklerinin tamamını kapsar. Sızma testini, güvenlik kontrollerinin amaçlandığı şekilde çalışıp çalışmadığını doğrulamak için kullanılan birçok teknikten yalnızca biri olarak ele alır.
Bu çerçevenin üç temel amacı vardır:
- Sistemlerde, ağlarda ve uygulamalarda bulunan güvenlik açıklarını belirlemek.
- Güvenlik kontrollerinin, saldırgan koşullar altında beklendiği gibi çalışıp çalışmadığını test ederek doğrulamak.
- Gerçek dünya saldırı senaryolarını simüle ederek, bir tehdit aktörünün belirlenen zayıflıkları gerçekten kullanıp kullanamayacağını değerlendirmek.
Aşamalar: Genel Bakış (Phases: A Walkthrough)
NIST Special Publication 800-115, güvenlik testlerini üç aşamada yapılandırır. Bunu bir senaryo üzerinden inceleyelim: Ekibiniz, GovNet adlı orta ölçekli bir federal kurumun güvenliğini değerlendirmekle görevlendirildi. Bu kurum; 500 host, 3 veri merkezi ve vatandaş hizmetleri sunan internet erişimine açık bir portaldan oluşan dahili bir ağa sahiptir.Aşama 1: Planlama (Planning)
Herhangi bir test başlamadan önce hedefler, kapsam ve angajman kuralları resmî olarak tanımlanır ve belgelenir. GovNet örneğinde bu, hangi ağ segmentlerinin kapsam dahilinde olduğunu (vatandaş portalı ve onu destekleyen arka uç sistemleri) ve hangilerinin kapsam dışında bırakıldığını (gizli sınıflandırılmış ağ bölgesi) belirlemek anlamına gelir.Ayrıca iletişim protokolleri de tanımlanır:
- Test sırasında kritik bir güvenlik açığı bulunursa kimin bilgilendirileceği,
- Testlerin hangi saatlerde yapılmasına izin verildiği,
- Hangi durumların acil durdurma koşulu sayılacağı belirlenir.
Aşama 2: Yürütme (Execution)
Bu aşama aktif testlerin gerçekleştirildiği bölümdür. NIST SP 800-115, yürütme faaliyetlerini dört teknik kategori altında toplar:1. İnceleme Teknikleri (Review Techniques)
Dokümantasyonun, politikaların, sistem yapılandırmalarının ve kural setlerinin incelenmesini kapsar. GovNet örneğinde bu, güvenlik duvarı kuralları ve erişim kontrol listelerinin yanlış yapılandırmalar açısından değerlendirilmesini içerir.2. Hedef Belirleme ve Analiz (Target Identification and Analysis)
Canlı sistemlerin, açık portların ve çalışan servislerin keşfedilmesi ve tanımlanmasını kapsar. GovNet ortamında vatandaş portalı altyapısı taranır ve internete açık 12 servis tespit edilir.3. Hedef Güvenlik Açığı Doğrulaması (Target Vulnerability Validation)
Tespit edilen zafiyetlerin gerçekten var olup olmadığının ve istismar edilebilirliğinin doğrulanmasıdır. GovNet senaryosunda bir tarama aracı, portalın arama fonksiyonunda olası bir SQL injection açığı tespit eder. Bu durum, veritabanı sürüm bilgisini döndüren özel hazırlanmış bir sorgu ile manuel olarak doğrulanır.4. Sızma Testi (Penetration Testing)
Gerçek saldırgan davranışlarını simüle ederek ne düzeyde istismar yapılabileceğini test etmeyi içerir. GovNet örneğinde doğrulanan SQL injection açığı, veritabanı sunucusundaki bir yetki yükseltme açığıyla birleştirilir ve dışarıdan bir saldırganın vatandaş kayıtlarına erişebileceği gösterilir.NIST SP 800-115’in bu teknikleri pasiften aktife, düşük etkiden yüksek etkiye doğru ilerleyen bir süreç olarak ele aldığına dikkat edin. Her güvenlik değerlendirmesinin mutlaka tam kapsamlı sızma testine ulaşması gerekmez; bazı durumlarda yalnızca inceleme ve güvenlik açığı doğrulaması bile yeterli olabilir.
Aşama 3: Test Sonrası (Post-Testing)
Bu aşamada odak noktası; sonuçların analiz edilmesi, risklerin önceliklendirilmesi ve uygulanabilir çözüm önerilerinin sunulmasıdır.GovNet örneğinde:
- Bulgular önem derecelerine göre sınıflandırılır (SQL injection zinciri kritik, eksik bir HTTP güvenlik başlığı ise düşük seviyeli olarak değerlendirilir).
- Her bulgu, hangi güvenlik kontrolünü atlattığıyla eşleştirilir.
- Somut düzeltme adımları sunulur.
Kapanış Notları
NIST Special Publication 800-115’in güçlü yönleri arasında esnekliği ve kurumsal güvenilirliği yer alır. Belirli araçları zorunlu kılmak yerine teknik kategorileri tanımladığı için, geleneksel veri merkezlerinden bulut altyapılarına ve IoT dağıtımlarına kadar farklı ortamlara kolayca uyarlanabilir. Ayrıca NIST ile ilişkilendirilmesi, özellikle devlet kurumları, savunma sektörü ve düzenlemelere tabi endüstrilerde ona güçlü bir güvenilirlik kazandırır. Bunun yanında standartlaşmayı teşvik ederek, birden fazla test ekibine sahip organizasyonların tutarlı kaliteyi korumasını kolaylaştırır.Bununla birlikte bazı dezavantajları da vardır. NIST SP 800-115, denetim sıklıkları veya yaptırımlar konusunda zorunluluk getirmez. Örneğin PCI DSS yıllık sızma testlerini zorunlu tutarken, NIST SP 800-115 bir düzenleme değil, rehber niteliğindedir. Bu durum, özellikle yoğun şekilde regüle edilen sektörlerde tek başına yeterli bir uyumluluk aracı olarak kullanılmasını sınırlayabilir.
Ayrıca çerçeve, yetkin uzmanlar gerektirir. Çünkü metodoloji; doküman incelemesinden gerçek istismar (exploitation) faaliyetlerine kadar tüm tekniklerin uygulanabileceğini varsayar. Bu da test uzmanlarının geniş kapsamlı teknik bilgi ve deneyime sahip olmasını zorunlu kılar.
PTES
Genel Bakış
Şimdiye kadar bilimsel metriklere odaklanan OSSTMM, web uygulaması kapsamını merkeze alan OWASP Web Security Testing Guide (WSTG) ve devlet standartlarına uyumlu değerlendirme tekniklerini temel alan NIST Special Publication 800-115 gibi çerçeveleri gördünüz. Ancak burada düşünmeye değer bir soru var: Eğer yarın bir kurumsal ağ için standart bir sızma testi görevi alsaydınız, ilk müşteri görüşmesinden nihai rapor teslimine kadar izleyeceğiniz gerçek iş akışına en çok hangi metodoloji benzerdi?Birçok profesyonel sızma testi uzmanı için cevap, Penetration Testing Execution Standard (PTES) olurdu. PTES, deneyimli güvenlik uzmanlarından oluşan bir grup tarafından, “gerçek bir sızma testinin baştan sona nasıl yürütüldüğünü” tanımlamak amacıyla geliştirilmiştir. Diğer çerçeveler daha çok “neyin test edileceğine” veya “nasıl ölçüleceğine” odaklanırken, PTES bir sızma testi sürecinin başlangıçtan sona nasıl ilerlediğine odaklanır.
PTES, bir sızma testi çalışmasının yaşam döngüsünü doğrudan yansıtan yedi aşamadan oluşur. Bu yaklaşım özellikle yeni başlayan test uzmanları için oldukça pratiktir; çünkü birçok metodolojinin dolaylı bıraktığı şu soruya doğrudan cevap verir:
“İmzalanmış bir sözleşmem var; şimdi ilk gün, ikinci gün ve sonraki günlerde tam olarak ne yapacağım?”
Aşamalar: Genel Bakış (Phases: A Walkthrough)
Penetration Testing Execution Standard (PTES)’in yedi aşamasını bir senaryo üzerinden inceleyelim: MedGuard Health adlı bir sağlık şirketi, kurumsal ağını ve hasta kayıt portalını test etmek için ekibinizi tam kapsamlı bir sızma testi gerçekleştirmesi amacıyla görevlendiriyor.Aşama 1: Ön Etkileşim Süreci (Pre-Engagement Interactions)
Bu aşama, test başlamadan önce gerçekleşen tüm faaliyetleri kapsar. MedGuard’ın BT direktörüyle birlikte kapsam belirlenir:- Kurumsal LAN ağı (10.10.0.0/16)
- Hasta portalı (records.medguard-health.thm)
- Merkez binadaki kablosuz ağlar
- Testlerin yalnızca hafta içi geceleri yapılması (klinik operasyonları etkilememek için)
- Acil durum iletişim kişileri
- Testin yetkili olduğunu gösteren “get out of jail free” yetki belgesi
Aşama 2: İstihbarat Toplama (Intelligence Gathering)
Bu aşamada MedGuard hakkında hem pasif hem de aktif yöntemlerle bilgi toplanır.Pasif keşif örnekleri:
- LinkedIn üzerinden çalışan e-posta adreslerinin toplanması
- Certificate transparency loglarından alt alan adlarının keşfedilmesi
- Teknoloji altyapısını ortaya çıkaran iş ilanlarının incelenmesi
(“Oracle 19c deneyimine sahip DBA aranıyor” gibi)
- DNS enumeration
- Belirlenen kapsam dahilinde ağ taramaları
Aşama 3: Tehdit Modellemesi (Threat Modeling)
Toplanan bilgiler kullanılarak en değerli hedefler ve en olası saldırı yolları belirlenir.MedGuard ortamında en değerli varlık hasta kayıt veritabanıdır. Tehdit modeli iki ana saldırı yolu ortaya koyar:
- Hasta portalının bir web zafiyeti üzerinden doğrudan ele geçirilmesi
- Bir çalışan iş istasyonunun ele geçirilmesinden sonra kurumsal ağ üzerinden içeri sızılması
Aşama 4: Güvenlik Açığı Analizi (Vulnerability Analysis)
Bu aşamada, tehdit modelindeki saldırı yollarını mümkün kılabilecek zafiyetler sistematik olarak belirlenir.MedGuard örneğinde:
- Güvenlik açığı taraması, hasta portalının eski bir Apache Tomcat sürümü kullandığını ortaya çıkarır.
- Bu sürümde bilinen bir deserialization açığı bulunmaktadır.
- Dahili ağda ise bazı iş istasyonlarının kritik yamalarının eksik olduğu görülür.
Aşama 5: İstismar (Exploitation)
Bu aşamada doğrulanan güvenlik açıkları istismar edilmeye çalışılır.MedGuard ortamında:
- Tomcat deserialization açığı kullanılarak portal sunucusunda shell erişimi elde edilir.
- Dahili tarafta ise kapsam dahilinde izin verilen bir phishing senaryosu kullanılarak çalışan iş istasyonuna payload gönderilir.
Aşama 6: İstismar Sonrası (Post-Exploitation)
Erişim sağlandıktan sonra gerçek dünya etkisi değerlendirilir.Örnekler:
- Ele geçirilen portal sunucusundan arka uç veritabanına geçiş yapılır ve hasta kayıtlarına okuma erişimi doğrulanır.
- Çalışan iş istasyonundan önbelleğe alınmış domain kimlik bilgileri elde edilir.
- Finansal veriler içeren dosya sunucusuna yatay hareket (lateral movement) gerçekleştirilir.
Örneğin:
- “Shell erişimi elde edildi” demektense
- “50.000 hasta kaydına erişildi” ifadesi çok daha güçlü bir etki yaratır.
Aşama 7: Raporlama (Reporting)
Son aşamada bulgular yapılandırılmış bir rapor hâlinde sunulur. Rapor iki farklı hedef kitleye yönelik hazırlanır.Yönetici Özeti (Executive Summary)
MedGuard yöneticileri için iş riskleri sade bir dille açıklanır:- Hasta verilerine erişilebildiği
- HIPAA kapsamında ciddi düzenleyici risk bulunduğu
- Acil düzeltme gerektiği belirtilir
Teknik Rapor
BT ekibinin sorunları yeniden üretip çözebilmesi için ayrıntılar sağlanır:- Tam istismar adımları
- Etkilenen sistemler
- Kanıt ekran görüntüleri
- Önceliklendirilmiş çözüm önerileri
Kapanış Notları
Penetration Testing Execution Standard (PTES)’in en büyük gücü, pratik ve uçtan uca yapılandırılmış yaklaşımıdır. Gerçek bir sızma testi sürecinin nasıl ilerlediğini adım adım anlatan bir oyun kitabı (playbook) gibi okunabilir. Bu nedenle özellikle iş akışı alışkanlıklarını geliştirmeye çalışan yeni başlayan sızma testi uzmanları için oldukça değerli bir öğrenme çerçevesidir.Özellikle “ön etkileşim süreci” (pre-engagement interactions) konusundaki ayrıntılı yaklaşımı dikkat çekicidir. Birçok metodoloji kapsam belirleme ve yasal yetkilendirme süreçlerini yüzeysel geçerken, PTES bu konulara özel önem verir. Oysa deneyimsiz test uzmanlarının en maliyetli hataları genellikle tam da bu alanlarda ortaya çıkar.
Bununla birlikte bazı dezavantajları da vardır. PTES birkaç yıldır resmî olarak güncellenmemiştir ve teknik rehber bölümlerinde eski araçlar ile güncelliğini yitirmiş tekniklere referans verilmektedir. Metodolojinin temel yapısı ve aşamaları hâlâ güçlü olsa da, test uzmanlarının araç ve tekniklerle ilgili bölümleri güncel dokümantasyonlarla desteklemesi gerekir.
Ayrıca OSSTMM’de bulunan niceliksel metriklere sahip değildir. Bu nedenle sonuçlar, test uzmanının deneyimine ve kişisel değerlendirmesine daha fazla bağlıdır.
ISSAF
Genel Bakış
Hiç eski bir ders kitabını inceleyip, yaşına rağmen temel mantığının hâlâ geçerli olduğunu fark ettiniz mi? Siber güvenlikte araçlar ve exploitler kısa bir ömre sahiptir, ancak iyi tasarlanmış metodolojiler, test ettikleri teknolojilerden çok daha uzun süre dayanabilir. Bilgi Sistemleri Güvenlik Değerlendirme Çerçevesi (ISSAF - Information Systems Security Assessment Framework) bu duruma iyi bir örnektir.
Açık Bilgi Sistemleri Güvenliği Grubu (OISSG - Open Information Systems Security Group) tarafından geliştirilen ISSAF, ağ, sistem ve uygulama güvenliğini değerlendirmek için tasarlanmış açık kaynaklı bir sızma testi çerçevesidir. En son sürümü olan ISSAF v0.2.1 yaklaşık 2006 yılında yayımlanmıştır ve artık aktif olarak geliştirilmemektedir. Güncel bir resmî indirme kaynağı bulunmamaktadır; ancak taslak sürüm hâlâ arşivlenmiş kaynaklar üzerinden erişilebilir durumdadır. Bu önemli bir bağlamdır: ISSAF’in metodolojisi ve aşama yapısı öğretici olmaya devam etse de, araçlara özel teknik rehberi güncelliğini yitirmiştir ve güncel çalışmalar için güvenilir bir kaynak olarak kullanılmamalıdır.
Peki neden artık geliştirilmeyen bir çerçeveyi inceleyelim? Çünkü ISSAF’in dokuz adımlı değerlendirme modeli, bir saldırganın hedef bir sistem içinde nasıl ilerlediğini en net gösteren yapılardan biridir. Bu model, bir ileri düzey kalıcı tehdit (APT - Advanced Persistent Threat) mantığını taklit eder; başlangıç keşfinden kalıcı erişime ve izlerin silinmesine kadar sistematik bir ilerleyiş izler. Bu ilerleyiş size tanıdık geliyorsa, bunun nedeni daha önce bu modül içinde ayrıntılı olarak ele aldığınız Cyber Kill Chain yaklaşımıyla aynı mantığı paylaşmasıdır.Information Systems Security Assessment Framework (ISSAF); ağ altyapısı, sunucu sistemleri, web uygulamaları, veritabanları ve sosyal mühendislik gibi geniş bir güvenlik alanını kapsar. Risk tabanlı yaklaşımı sayesinde, düşük önem derecesine sahip bulgulardan ziyade yüksek etki yaratabilecek ve istismar edilebilir güvenlik açıklarına öncelik verir.
Aşamalar: Genel Bakış (Phases: A Walkthrough)
Information Systems Security Assessment Framework (ISSAF) bir güvenlik değerlendirmesini üç ana aşamaya böler. Bunu bir senaryo üzerinden inceleyelim: Ekibiniz, 200 çalışanı olan TechBridge Solutions adlı bir yazılım geliştirme şirketinin güvenliğini değerlendiriyor. Şirketin bir iç Git sunucusu ve müşterilere yönelik bir proje yönetim portalı bulunmaktadır.Aşama 1: Planlama ve Hazırlık (Planning and Preparation)
Bu aşama, testin sınırlarını belirler. TechBridge’in CTO’su ile görüşülerek kapsam tanımlanır:- Kurumsal ağ
- Git sunucusu
- Proje yönetim portalı
- Eskalasyon (escalation) prosedürleri ve acil durum iletişim bilgileri belirlenir
- Kısıtlamalar netleştirilir (örneğin üretim Git sunucusu iş saatlerinde kesintiye uğratılmamalıdır)
- Kullanılacak araçlar ve test yöntemleri üzerinde anlaşma sağlanır
Aşama 2: Değerlendirme (Assessment)
Bu aşama ISSAF’in çekirdeğini oluşturur ve dokuz adımlı model burada uygulanır. Her adım bir öncekinin üzerine inşa edilerek gerçek bir saldırganın sistemde nasıl ilerleyeceğini simüle eder.1. Bilgi Toplama (Information Gathering)
TechBridge hakkında halka açık bilgiler toplanır:- DNS kayıtları
- WHOIS bilgileri
- LinkedIn çalışan profilleri
- İş ilanlarındaki teknoloji referansları (örneğin Jenkins ve GitLab CI kullanımı)
2. Ağ Haritalama (Network Mapping)
Ağ topolojisi çıkarılır:- Dış IP aralığında proje portalı, VPN gateway ve mail sunucusu bulunur
- İç ağ taramasıyla Git sunucusu, Jenkins build server ve geliştirici makineleri tespit edilir
3. Güvenlik Açığı Belirleme (Vulnerability Identification)
Varlıklar taranır:- Proje portalında eski bir CMS ve kimlik doğrulama bypass açığı
- Jenkins sunucusunda kimlik doğrulama olmadan erişilebilen admin konsolu
4. Sızma (Penetration)
İlk istismar girişimleri yapılır:- Jenkins konsolu kullanılarak sunucu üzerinde komut çalıştırma elde edilir
5. Erişim ve Yetki Yükseltme (Gaining Access and Privilege Escalation)
Elde edilen erişim genişletilir:- Jenkins üzerinden production deploy eden servis hesabı kimlik bilgileri elde edilir
- Bu hesap Git sunucusunda yönetici yetkisine sahiptir
6. Daha Fazla Keşif (Enumerating Further)
Yetkiler kullanılarak sistemler incelenir:- Git reposlarında API anahtarları, veritabanı bağlantı stringleri ve kaynak kodlar bulunur
7. Yanal Hareket (Lateral Movement)
Diğer sistemlere geçiş yapılır:- Geliştirici iş istasyonlarına ve iç mail sunucusuna erişim sağlanır
8. Kalıcılık Sağlama (Maintaining Access)
Kalıcı erişim yöntemleri analiz edilir:- CI/CD pipeline’a backdoor eklenebileceği belgelenir
- Böylece sistem yeniden başlatılsa bile erişim korunabilir
9. İzleri Gizleme (Covering Tracks)
Saldırganın logları silme veya gizleme yöntemleri değerlendirilir:- Yapılan aktivitelerin hangi loglara yazıldığı belirlenir
- Organizasyonun loglama zafiyetleri tespit edilir
Aşama 3: Raporlama ve Temizlik (Reporting and Cleanup)
Bulgular, iş etkisine göre önceliklendirilmiş yapılandırılmış bir raporda sunulur. Örneğin:- Jenkins üzerindeki kimlik doğrulama olmadan erişim sağlayan konsol, kritik olarak işaretlenir çünkü tüm zincirleme erişimin başlangıç noktasıdır
- Test sırasında oluşturulan tüm artefaktlar kaldırılır
- Oluşturulmuş geçici hesaplar silinir
- Ortamda testten kalan hiçbir izinli kalıntı olmadığı doğrulanır
- TechBridge ekibiyle birlikte sistemin temiz duruma döndüğü teyit edilir
Kapanış Notları
Information Systems Security Assessment Framework (ISSAF)’in en kalıcı katkısı dokuz adımlı modelidir. Bilgi toplamadan yanal harekete ve izleri gizlemeye kadar uzanan bu ilerleyiş, gerçek dünyadaki saldırıların nasıl gerçekleştiğine dair net bir zihinsel model sunar. Bu nedenle çerçevenin kendisi artık aktif olarak geliştirilmemiş olsa bile, eğitim açısından oldukça değerli bir araç olmaya devam eder.Bununla birlikte, güncellenmemiş olması önemli bir sınırlamadır. Araçlara özgü rehber bölümleri, günümüzden on yılı aşkın süre önceki yazılım sürümlerine atıfta bulunur ve bu dokümantasyonu güncelleyen aktif bir topluluk bulunmamaktadır. Bu nedenle ISSAF, teknik prosedürleri için değil, metodolojisi ve saldırgan mantığını anlamak için çalışılmalıdır.
Güncel araç ve teknikler için Penetration Testing Execution Standard (PTES), OWASP Web Security Testing Guide (WSTG) veya kullanılan araçların güncel dokümantasyonu gibi kaynaklarla desteklenmesi önerilir.
MITRE ATT&CK
Genel Bakış
Önceki bölümlerde, sızma testinin nasıl yürütüleceğini anlatan çerçeveleri incelediniz: kapsam belirleme, aşamaların ilerletilmesi ve bulguların raporlanması gibi süreçleri tanımlayan modeller. Örneğin Penetration Testing Execution Standard (PTES) kullanılarak yapılan bir çalışmada, kimlik avı e-postasıyla ilk erişim elde edildiğini, yanlış yapılandırılmış bir servis üzerinden yetki yükseltildiğini, çalınan kimlik bilgileriyle ağ içinde yatay hareket yapıldığını ve verilerin şifreli bir kanal üzerinden dışarı aktarıldığını raporlamış olabilirsiniz.Bu raporu alan müşteri ise basit ama kritik bir soru sorar: “Bizim saldırı yüzeyimiz, gerçek dünyada saldırganların yaptığı şeylerle ne kadar örtüşüyor?”
Bu soruya tek başına bir sızma testi çerçevesiyle net cevap vermek zordur. PTES ve OSSTMM gibi metodolojiler testin nasıl yapılacağını yapılandırır, ancak gerçek saldırganların hangi teknikleri kullandığını sistematik olarak sınıflandırmaz. İşte bu boşluğu dolduran yapı MITRE ATT&CK’tir.
ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge), MITRE Corporation tarafından geliştirilmiş ve sürdürülen bir bilgi tabanıdır. Geleneksel bir sızma testi çerçevesi değildir. Bunun yerine, gerçek dünyadaki tehdit aktörlerinin nasıl davrandığını gözlemleyerek oluşturulmuş bir saldırgan davranışları kataloğudur.
ATT&CK, saldırganların “ne yaptığını” sistematik bir şekilde sınıflandırır. Bu yapı, güvenlik uzmanlarının:
- tehdit istihbaratı üretmesinde,
- tespit (detection) mühendisliğinde,
- red team çalışmalarında,
- ve sızma testi bulgularını zenginleştirmede
ATT&CK Matrisi: Taktikler, Teknikler ve Alt Teknikler
MITRE ATT&CK bir matris (matrix) yapısı olarak organize edilmiştir. Bunu büyük bir tablo gibi düşünebilirsiniz.Bu tablonun sütunları taktikleri temsil eder. Taktikler, saldırganın üst düzey hedefleridir; yani “neden” bu işlemi yaptığıdır. Güncel Enterprise ATT&CK matrisi 14 taktik içerir ve şu ilerleyişi kapsar: ilk erişimden (initial access) başlayarak yürütme (execution), kalıcılık (persistence), yetki yükseltme (privilege escalation), savunma atlatma (defense evasion), kimlik bilgisi erişimi (credential access), keşif (discovery), yanal hareket (lateral movement), veri toplama (collection), komuta ve kontrol (command and control), veri sızdırma (exfiltration) ve etki (impact) aşamalarına kadar uzanır.
Her taktik sütununun altında ise teknikler (techniques) yer alır. Teknikler, saldırganın bir taktik hedefe ulaşmak için kullandığı spesifik yöntemlerdir; yani “nasıl” yapıldığını açıklar.
Örneğin Initial Access (İlk Erişim) taktiği altında şu teknikler bulunur:
- Phishing (T1566)
- Exploit Public-Facing Application (T1190)
- Valid Accounts (T1078)
- Spearphishing Attachment (T1566.001)
- Spearphishing Link (T1566.002)
- Spearphishing via Service (T1566.003)
Her teknik girdisi; açıklama, bu tekniği kullanan gerçek tehdit gruplarının örnekleri, tespit (detection) önerileri ve azaltma (mitigation) yöntemleri gibi bilgiler içerir. Bu da ATT&CK’i yalnızca bir sınıflandırma sistemi olmaktan çıkarır ve onu gözlemlenmiş saldırgan davranışlarına dayalı yaşayan bir referans haline getirir.
ATT&CK: Bir Tamamlayıcı, Yerine Geçen Değil
Bu bölümdeki en önemli ayrım şudur: MITRE ATT&CK bir sızma testinin nasıl yürütüleceğini anlatmaz. Yani kapsam belirleme, test aşamaları veya raporlama formatı gibi süreçleri tanımlamaz.Bunun yerine, herhangi bir metodolojiyle (örneğin Penetration Testing Execution Standard (PTES)) gerçekleştirilen bir test sırasında ortaya çıkan bulguları ifade etmek için ortak bir dil sağlar.
Bunu anlamak için şu analoji oldukça açıklayıcıdır:
- PTES, bir doktorun hastayı muayene ederken izlediği adım adım prosedür gibidir. Yani ne yapılacağını, hangi sırayla yapılacağını belirler.
- ATT&CK, tıbbi terimler sözlüğü gibidir. Doktorun gözlemlediği durumları standart bir dilde adlandırmasını ve sınıflandırmasını sağlar.
- Biri süreci yönetir
- Diğeri gözlemi standartlaştırır
Uygulamalı Örnek: Bulguları ATT&CK ile Eşleme
Bunu pratikte nasıl kullanacağınızı görmek için MedGuard Health senaryosunu hatırlayalım. Penetration Testing Execution Standard (PTES) kapsamında yapılan bu çalışmada elde edilen temel bulgular, MITRE ATT&CK teknik kimlikleriyle şu şekilde eşleştirilebilir:| Eylem (Engagement Finding) | ATT&CK Taktikleri | ATT&CK Teknikleri |
|---|---|---|
| Bir çalışanın iş istasyonuna kötü amaçlı yük içeren kimlik avı e-postası teslim edildi | İlk Erişim | Kimlik Avı: Hedefli Ek İçeren Kimlik Avı (T1566.001) |
| Hasta portalındaki Tomcat serileştirme açığı istismar edildi | İlk Erişim | Açıkta Olan Uygulamayı İstismar Etme (T1190) |
| İş istasyonundan önbelleğe alınmış etki alanı kimlik bilgileri çıkarıldı | Kimlik Bilgisi Erişimi | İşletim Sistemi Kimlik Bilgisi Dökümü (T1003) |
| Çalınan kimlik bilgileri kullanılarak iş istasyonundan dosya sunucusuna geçiş yapıldı | Yanal Hareket | Alternatif Kimlik Doğrulama Materyali Kullanma (T1550) |
| Ele geçirilmiş portal sunucusu üzerinden hasta kayıt veritabanına erişildi | Toplama | Bilgi Depolarından Veri Erişimi (T1213) |
Kapanış Notları
ATT&CK’in gücü, saldırgan davranışlarını evrensel bir çevirmen gibi standartlaştırabilmesinde yatar. Bu sayede sızma testi uzmanları, tehdit istihbaratı analistleri, tespit mühendisleri ve olay müdahale ekipleri aynı dili konuşabilir. Özellikle sızma testi uzmanları için bulguları ATT&CK ile eşleştirmek, bir raporu yalnızca zafiyet listesinden çıkararak gerçek dünya tehdit davranışlarına dayanan bir anlatıya dönüştürür.
Bu bilgi tabanı oldukça kapsamlıdır ve ustalaşmak zaman gerektirir. Sadece Enterprise matrisi bile 200’den fazla teknik içerir. ATT&CK’i daha derin ve uygulamalı şekilde keşfetmek
Karşılaştırma Tablosu
| Çerçeve | Birincil Alan | Tür | Aktif Olarak Bakımı Yapılıyor | Ne Zaman Kullanılır |
|---|---|---|---|---|
| WASC Tehdit Sınıflandırması | Web uygulamaları | Tehdit taksonomisi | Hayır (OWASP tarafından yerini almıştır) | Eski referanslar; tarihsel bağlam |
| CSA Bulut Kontrol Matrisi | Bulut ortamları | Yönetişim/uyumluluk kontrolleri | Evet | Bulut güvenlik duruşu değerlendirmeleri |
| OWASP Mobil Uygulama Güvenlik Test Rehberi | Mobil uygulamalar (Android/iOS) | Test rehberi | Evet | Mobil uygulama sızma testleri |
| PCI DSS Sızma Testi Yönergeleri | Ödeme kartı ortamları | Regülasyon zorunluluğu | Evet (güncel: PCI DSS v4.0) | Kart sahibi verisi içeren tüm çalışmalar |
| CBEST | Birleşik Krallık finans sektörü | Tehdit istihbaratı odaklı sızma testi | Evet | Birleşik Krallık finans kurumlarıyla yapılan çalışmalar |
| Çerçeve | Kapsam | Temel Güç | Sınırlama | En Uygun Olduğu Durum |
|---|---|---|---|---|
| OSSTMM | Çok kanallı (5 kanal) | Nicel ölçülebilir metrikler (RAV’ler) | Öğrenme eğrisi dik | Tekrarlanabilir, denetlenebilir değerlendirmeler |
| OWASP WSTG | Web uygulamaları | 90+ yapılandırılmış test senaryosu | Checklist (kontrol listesi) yaklaşımını teşvik edebilir | Web uygulama sızma testleri |
| NIST SP 800-115 | Sistemler, ağlar, uygulamalar | Federal düzeyde güvenilirlik; esnek teknik kategoriler | Sadece rehberdir, bağlayıcılığı yok | Kamu ve kurumsal değerlendirmeler |
| PTES | Uçtan uca çalışmalar | Pratik, aşamalı iş akışı | Güncel değil | Standart ağ/uygulama sızma testleri |
| ISSAF | Ağlar, sistemler, uygulamalar | Net dokuz aşamalı saldırgan ilerleyişi | Artık bakım yapılmıyor | Saldırı metodolojisi için eğitimsel referans |
| MITRE ATT&CK | Saldırgan davranış kataloğu | Tehdit davranışı için evrensel dil | Bir test metodolojisi değildir | Herhangi bir çerçeveden gelen bulguları zenginleştirme |
| OWASP MSTG | Mobil uygulamalar (Android/iOS) | Platforma özgü mobil test senaryoları | Sadece mobil kapsam | Mobil uygulama güvenlik testleri |
| PCI DSS Yönergeleri | Ödeme kartı ortamları | Regülasyon zorunluluğu | Dar kapsamlı | Kart verisi içeren çalışmalar |
| CSA CCM | Bulut ortamları | Büyük standartlarla eşlenmiş yönetişim kontrolleri | Sızma testi metodolojisi değildir | Bulut güvenlik duruşu değerlendirmeleri |
| CBEST | Birleşik Krallık finans sektörü | Tehdit istihbaratı odaklı, regülasyon destekli | Sadece UK finans sektörü | Birleşik Krallık finans kurumu çalışmaları |
| WASC Tehdit Sınıflandırması | Web uygulamaları | Tarihsel taksonomi | OWASP tarafından yerini almıştır | Sadece eski referans olarak |
Okuduğunuz için teşekkür ederimCW-Ommah
Bug Researchers Tim Sundu...
Bug Researchers Tim Sundu...
