Otonom Sızma Testi Platformu Nasıl Değerlendirilir? Pilot Planı ve Puan Kartı

Başarısız değerlendirmelerin çoğu burada başarısız olur: pilot, iyi bir sonucun ne olduğu üzerinde kimse uzlaşmadan başlar.

1. 1Temsili bir kapsam seçin. Gerçek iş yüklerinin bulunduğu bir ya da iki iç segment, kullanıyorsanız bir Active Directory etki alanı ve dış saldırı yüzeyinin bir bölümü. Temiz bir laboratuvar, aracı tam da bulması için satın aldığınız sorunları gizler.
2. 2Angajman kurallarını yazın. Hariç tutulan sunucular ve aralıklar, test pencereleri, üretimde asla izin verilmeyen eylemler, testi kimin durdurabileceği ve bu kişilere nasıl ulaşılacağı.
3. 3Bilinen zafiyetler yerleştirin. Bir test segmentinde, ekibinizin zaten iyi bildiği birkaç sorun oluşturun: yeniden kullanılmış bir yerel yönetici parolası, yaması yapılmamış bir servis, gereğinden geniş yetkili bir paylaşım. Bunlar, kaçırılanları ölçmek için size bilinen bir yanıt sağlar.
4. 4Başarıyı yazılı olarak tanımlayın. Örneğin: kapsam dışında hiçbir eylem yok, her bulgu kanıtlanmış, geçersiz bulgular sizin belirlediğiniz bir seviyenin altında, yerleştirilen zafiyetlerin çoğu bulunmuş, düzeltilen sorunlarda yeniden test çalışıyor.
5. 5Durdurma koşullarını tanımlayın. Kapsam dışındaki herhangi bir eylem, onaylanmamış herhangi bir hizmet kesintisi ya da ortamdan dışarı çıkan herhangi bir veri pilotu sonlandırır.
6. 6Kişileri belirleyin. Sizin tarafınızda bir sorumlu, onay gerektiren eylemler için onaylayıcılar ve bulguları inceleyecek analistler.

Önce güvenliği test edin; çünkü kontrol edilemeyen bir platform sık çalıştırılamaz ve onu satın almanın nedeni de sıklıktır.

• Kesin kapsam. Kapsamdaki bir aralığın içine hariç tutulan bir sunucu koyun ve ajanın ona hiç dokunmadığını, bir deneme olduysa kaydedildiğini kontrol edin. Kapsam, modelin takdirine bırakılmamalı; platform tarafından uygulanmalıdır.
• Acil durdurma. Bir çalışmanın ortasında tetikleyin. Çalışan her eylem durmalı ve kayıt bunun ne zaman olduğunu göstermelidir.
• Onay kapıları. Hangi eylemlerin kendiliğinden çalıştığını, hangilerinin bir insanı beklediğini ve bunu kampanya bazında değiştirip değiştiremeyeceğinizi sorun. Her onay, kimin neyi ne zaman onayladığını kaydetmelidir. Bkz. human-in-the-loop yapay zekâ güvenlik testleri.
• Hız ve etki sınırları. Platformun OT, yazıcılar ya da eski sunucular gibi kırılgan sistemlerde yükü, hesap kilitlenmelerini ve kesinti yaratabilecek teknikleri nasıl sınırladığını kontrol edin.
• Eksiksiz eylem kaydı. Ajanın çalıştırdığı her komutu, hangi sunucuda ve neden çalıştırdığını yeniden oluşturabilmelisiniz.

Otonom bir ajan, yalnızca bir sürüm bilgisinin ima ettiği bir zafiyeti tarif edebilir ya da başarısız olan bir exploit'in çalıştığına inanabilir. Bir bulguyu tahminden ayıran şey kanıttır.

• Her bulgu için şunları isteyin: kullanılan tam istek ya da teknik, hedefin yanıtı ve ajanın erişim sonrasında neler yapabildiği; zaman damgalarıyla birlikte.
• Kanıtların sonradan düzenlenemediğini kontrol edin. İmzalı ve zincirlenmiş kayıtlar, bir denetçinin raporun gerçekte olanlarla örtüştüğünü doğrulamasını sağlar.
• Üç bulgu seçin ve yalnızca kanıtlardan yola çıkarak kendi ekibinizle yeniden üretin. Üretemiyorlarsa, kanıtlar ne iyileştirme ne de bir denetçi için yeterince iyi değildir.
• Kanıtların neler içerdiğini kontrol edin. Ele geçirilen kimlik bilgileri ve veri örnekleri hassastır: nerede saklandıklarını, kimlerin görebildiğini ve sonunda nasıl silindiklerini sorun.

Gösterge panelinin gösterdiğini değil, analistlerinizin kabul ettiğini sayın.

• Geçersiz bulgular. Analistlerinizin her bulguyu geçerli, geçersiz ya da mükerrer olarak işaretlemesini sağlayın. Geçersiz olanların oranı, her hafta önceliklendirmede ödeyeceğiniz bedeldir. Yapay zekâ ajanlarını profesyonel sızma testi uzmanlarıyla karşılaştıran ICLR 2026 çalışmasında en iyi ajanın bile gönderimlerinin yaklaşık beşte biri reddedildi; bu nedenle her üreticiye bu oranı nasıl ölçtüğünü sorun.
• Kaçırılanlar. Sonuçları yerleştirdiğiniz zafiyetlerle karşılaştırın. Çok şey raporlayan ama bilinen sorunlarınızı kaçıran bir araç kapsamlı değil, gürültülüdür.
• Bağlamında önem derecesi. Önem derecesinin yalnızca CVSS puanını değil, bir saldırganın sizin ortamınızda bu bulgudan yola çıkarak nereye ulaşabileceğini yansıtıp yansıtmadığını kontrol edin.
• Mükerrerler ve gürültü. Tek bir kök neden, elli ayrı kayıt değil, etkilenen birçok sunucuyu içeren tek bir bulgu olmalıdır.

• Liste değil, saldırı yolları

  Otonom bir red team'in değeri zincirleme yeteneğindedir: zayıf bir kimlik bilgisinden bir sunucuya, oradan domain admin'e, oradan da hedef bir sisteme. En az bir yolun adım adım gösterilmesini isteyin.

• İç ve dış

  Her ikisini de kontrol edin; ajanın sıradan bir iş istasyonunda varsayılan ihlal (assumed breach) konumundan başlayıp başlayamayacağına da bakın.

• Kimlik

  Active Directory ve bulut kimlik yapılandırma hataları, gerçek saldırıların ilerlediği yerlerdir. Ajanın burada neleri test ettiğine ve bunu nasıl kanıtladığına bakın.

• Black-box ve gray-box

  Bir kez hiçbir kimlik bilgisi olmadan, bir kez de standart bir kullanıcı hesabıyla çalıştırın; aradaki fark, ajanın kendisine verdiklerinize ne kadar bağımlı olduğunu gösterir.

• Neleri test etmediği

  Özel uygulamalardaki iş mantığı, sosyal mühendislik ve fiziksel erişim genellikle insanların işi olarak kalır. Her şeyi yaptığını iddia eden bir üretici bir uyarı işaretidir.

Pilot birkaç hafta sürer; araç ise yıllarca çalışır. Etrafındaki işi puanlayın.

• Yeniden test. İki bulguyu düzeltin ve platformdan bunları yeniden test etmesini isteyin. Orijinal yolu yeniden oynatmalı ve artık çalışmadığını göstermelidir.
• Aktarım. Kayıt (ticket) sisteminize aktarımı ve iyileştirme önerilerini kontrol edin: sistemin sahibi olan ekip için yeterince somut mu?
• Raporlar. Yönetici özetine ve teknik rapora ayrı ayrı bakın; NIS2, DORA, PCI DSS ya da ISO 27001 gibi raporlama yaptığınız çerçevelerle eşlemeyi de inceleyin.
• Analist süresi. Bulgu başına önceliklendirmenin ne kadar sürdüğünü ölçün. Bu sayının çalıştırma sıklığıyla çarpımı, gerçek personel maliyetidir.
• Dağıtım ve veri. Modellerin nerede çalıştığı, ağdan nelerin çıktığı ve air-gap ortamında çalışıp çalışmadığı 15 soruluk on-premise satın alma kontrol listesinde ele alınıyor.

• Ağınızda pilot yok,

  yalnızca üreticinin laboratuvarında ya da herkese açık bir görev setinde demolar var.

• Yöntemi açıklanmayan benchmark puanları

  Üreticinin önceden inceleyebildiği görevlerde alınan bir puan kör değildir. Ölçümü kimin, neyin üzerinde yaptığını sorun.

• Kanıtsız bulgular,

  ya da ekran görüntüleri ve tarayıcı çıktısıyla sınırlı kanıtlar.

• Modele bağlı kapsam

  platformun uyguladığı bir sınır yerine modelin talimatlara uymasına dayanan bir kapsam.

• Kendinizin tetikleyebileceği bir acil durdurma yok,

  ya da devreye girmesi dakikalar sürüyor.

• Verileriniz ağdan çıkıyor

  çıkarım ya da analiz için, nereye gittiğine dair net ve sözleşmeye bağlanmış bir yanıt olmadan.

• "Sızma testi uzmanlarınızın yerini tamamen alır."

  DORA TLPT gibi düzenleyici liderliğindeki testler hâlâ insan ekipleri gerektirir.

1. 10. hafta: hazırlık. Kapsam, angajman kuralları, başarı ve durdurma kriterleri üzerinde uzlaşın; bilinen zafiyetleri yerleştirin; platformu kurun ve onaylayıcıları bağlayın.
2. 21. hafta: güvenlik testleri ve ilk çalıştırma. Kapsam denetimini ve acil durdurmayı bilinçli olarak test edin; ardından en temkinli otonomi seviyesinde dış saldırı yüzeyi ve bir iç segment üzerinde black-box bir kampanya çalıştırın.
3. 32. hafta: derinlik. Standart bir kullanıcı hesabıyla gray-box, varsayılan ihlal (assumed breach) kampanyası çalıştırın. Saldırı yollarını inceleyin ve analistlerin her bulguyu işaretlemesini sağlayın.
4. 43. hafta: düzeltme ve yeniden test. Birkaç bulguyu ve yerleştirilen zafiyetleri giderin, ardından yeniden test edin. Üç bulguyu yalnızca kanıtlardan yola çıkarak yeniden üretin.
5. 54. hafta: puanlama ve karar. Puan kartını doldurun, bulgu başına analist süresini ölçün ve 0. haftada yazdığınız kriterlerle karşılaştırın.

Pilottan önce otonom sızma testinin uçtan uca nasıl çalıştığını görmek için rehberle başlayın. Platformları önce kâğıt üzerinde karşılaştırmak için otomatik sızma testi araçları karşılaştırmasını ve gereksinimler için ortak bir dil olarak OWASP Autonomous Penetration Testing Standard'ı kullanın.

Otonom bir sızma testi pilotu ne kadar sürmeli? Genellikle iki ila dört hafta yeterlidir: bir hafta güvenlik testleri ve ilk çalıştırma, bir hafta daha derin bir gray-box çalıştırma, bir hafta düzeltme ve yeniden test, bir de puanlama için zaman. Daha kısa pilotlar nadiren yeniden test içerir; birçok aracın yetersiz kaldığı yer de tam burasıdır.

Üretim ortamında pilot yapmak güvenli mi? Yalnızca platform tarafından uygulanan bir kapsam, sizin kontrolünüzde bir acil durdurma ve kesinti yaratabilecek eylemler için insan onayı varsa. En temkinli otonomi seviyesinde ve bir kesintinin tolere edilebileceği segmentlerde başlayın.

Yanlış pozitifleri nasıl ölçerim? Analistlerinizin raporlanan her bulguyu geçerli, geçersiz ya da mükerrer olarak işaretlemesini sağlayın ve kaçırılanları ölçmek için bilinen zafiyetler yerleştirin. Her iki sayı da önemlidir: düşük yanlış pozitif oranı ile birlikte çok sayıda kaçırılan bulgu iyi bir sonuç değildir.

Üretici benchmark puanlarına güvenmeli miyim? Yalnızca ölçüm kör yapıldıysa ve üretici dışında biri tarafından yürütüldüyse. Üreticinin inceleyebildiği herkese açık görev setlerindeki sonuçlar kör değildir. Kendi ağınızda yapılan bir pilot daha iyi bir rehberdir.

Pilottan sonra sözleşmede neler yazmalı? Kapsam ve angajman kuralları, onay gerektiren eylemleri kimin onayladığı, verilerin ve modellerin nerede bulunduğu, kanıtların nasıl saklandığı ve silindiği ve yeniden test süreci. Yukarıda bağlantısı verilen on-premise satın alma kontrol listesi, veri ve dağıtım sorularını listeliyor.

Zero Hunt bu tabloda nerede duruyor? Zero Hunt, kendi modellerini çalıştıran on-premise bir appliance üzerinde otonom bir yapay zekâ red team'dir; bu sayede test verileri ağınızda kalır. Kapsam sınırları ve acil durdurma platform tarafından uygulanır, operatörler hangi eylemlerin onay bekleyeceğini belirleyen beş otonomi seviyesinden birini seçer ve her bulgu Ed25519 ile imzalanmış, hash zinciriyle bağlı kanıtlarla desteklenir. Henüz benchmark rakamı yayımlamamaktadır; değerlendirme metodolojisi hazırlanmaktadır ve burada anlatılan pilotla değerlendirilebilir.