Kırmızı takım bir tatbikat değil, bir regresyon hattıdır

Tez#

Kırmızı takım pratiği güvenlik dünyasından geldiği biçimiyle uygulanıyor: belirli bir kapsamda, belirli bir süreyle bir saldırı çalışması yapılır, bulgular raporlanır, düzeltmeler yapılır ve çalışma kapanır. Klasik yazılımda bu döngü mantıklı çünkü kapatılan bir açık kapalı kalıyor — kodda değişiklik yapılmadıkça yeniden açılmıyor.

Dil modeli sistemlerinde bu varsayım geçerli değil. Bir saldırı yolunun kapalı olması, koddaki bir kontrolden değil modelin davranışından kaynaklanıyor olabilir — ve model davranışı sürümler arasında değişiyor. Sağlayıcı bir güncelleme yayımladığında, daha önce reddedilen bir istek kabul edilebiliyor. Aynı şekilde istem şablonundaki bir düzenleme, araç tanımlarına eklenen bir alan veya geri getirme katmanındaki bir değişiklik, kapatılmış bir yolu yeniden açabiliyor. Bu yüzden kırmızı takım bulgusunun ömrü, düzeltmenin yapıldığı gün bitmiyor.

Bağlam: bulgunun yaşam döngüsü#

Tablo, aynı bulgunun iki farklı kurguda nasıl ele alındığını karşılaştırıyor. Fark, düzeltmeden sonra ne olduğunda.

Birinci satırdaki fark pratikte belirleyici. Bir bulgu düz metin olarak rapora yazıldığında, aylar sonra onu yeniden denemek için yeni bir çalışma gerekiyor — ve genellikle yapılmıyor. Aynı bulgu çalıştırılabilir bir vaka olarak kaydedildiğinde, her koşuda bedavaya sınanıyor. Bu dönüşümün maliyeti bulgu başına birkaç dakika; getirisi ise bulgunun ömrü boyunca sürekli.

Kanıt: regresyon setinin kapsaması gerekenler#

Bir kırmızı takım regresyon seti, klasik test setinden farklı kategoriler taşıyor. Aşağıdaki liste, dil modeli sistemlerinde ayrı ayrı izlenmesi gereken yolları veriyor.

• Doğrudan istem enjeksiyonu: kullanıcının kendi mesajıyla sistem talimatını geçersiz kılma denemeleri.
• Dolaylı istem enjeksiyonu: modelin okuduğu bir belgeye, bilete veya web içeriğine gömülü talimatlar. Ajan sistemlerinde en kritik kategori.
• Araç kötüye kullanımı: modelin meşru bir aracı beklenmedik bir amaç için çağırmaya ikna edilmesi.
• Veri sızdırma: sistem isteminin, bağlamdaki başka kullanıcı verisinin veya araç kimlik bilgilerinin çıktıya taşınması.
• Yetki sınırı aşma: bir kullanıcının kendi yetkisi dışındaki bir kaynağa modelin aracılığıyla erişmesi.
• Zararlı içerik yolları: reddedilmesi gereken isteklerin dolaylı biçimlerle kabul edilmesi.
• Türkçe ve karışık dil denemeleri: aynı saldırının Türkçe, karışık dilli ve harf çevrimli biçimleri. Filtreler genellikle İngilizce üzerinde sınanıyor.

Yedinci madde Türkçe ürünlerde belirgin bir boşluk ve nedeni yapısal. Koruma katmanları ve içerik filtreleri ağırlıklı olarak İngilizce örneklerle geliştirilip sınanıyor; aynı saldırı Türkçe yazıldığında, Türkçe ile İngilizce karıştırıldığında ya da Türkçe harfler ASCII karşılıklarıyla değiştirildiğinde filtre kaçırabiliyor. Bu, model kalitesinden bağımsız bir kapsama sorunu ve yalnızca Türkçe saldırı vakaları sete konularak ölçülebiliyor.

Mekanizma: neden kapatılan yol geri açılıyor#

Geri açılmanın nedeni, savunmanın nerede durduğuna bağlı. İki tür savunma var ve dayanıklılıkları çok farklı.

Birinci tür, modelin davranışına dayanan savunma: sistem istemine eklenen bir talimat, modelin belirli bir isteği reddetmesi, koruma modelinin bir girdiyi işaretlemesi. Bunlar olasılıksal ve sürüme duyarlı — model güncellendiğinde davranış değişiyor ve kapatılmış yol yeniden açılabiliyor. İkinci tür, koddaki sert kontroller: araç çağrısı öncesinde yetki denetimi, çıktıda belirli alanların maskelenmesi, dış ağ erişiminin tümden kapatılması. Bunlar sürüm değişiminden etkilenmiyor. Pratik sonuç şu: bir bulgu birinci tür bir savunmayla kapatıldıysa regresyon testi zorunlu; ikinci tür bir savunmayla kapatıldıysa test hâlâ yararlı ama geri açılma riski düşük. Bu yüzden her düzeltmenin hangi türe girdiği kaydedilmeli — çünkü test önceliği bunu izliyor.

Karşı görüş#

Üç itiraz güçlü. Birincisi: saldırı vakalarını kalıcı bir sette tutmak bu vakaları kurum içinde yayıyor ve bir iç risk üretiyor. İkincisi: saldırı yolları hızla eskiyor; eski vakaları koşmak boş zaman harcamak. Üçüncüsü: bu setin bakımı klasik test bakımından ağır çünkü başarısızlık ölçütü belirsiz — bir saldırının başarılı olup olmadığına kim karar veriyor?

Kırmızı takım bulgularını regresyona çevirdik. İki ay sonra bir sağlayıcı sürümüyle üç vaka yeniden geçti. Rapor kurgusunda olsaydık bunu ancak bir olaydan sonra öğrenirdik.

Birinci itiraz gerçek ve çözümü setin erişimini daraltmak: vakalar kod deposunda düz metin olarak değil, erişimi kısıtlı bir yerde tutulmalı ve koşu çıktıları içeriği açığa çıkarmamalı. İkinci itiraz kısmen doğru — bazı vakalar gerçekten eskiyor — ama eskime testi koşuyu bırakmakla değil, sonucu izlemekle yapılıyor: uzun süre hiç geçmeyen bir vaka arşivlenebilir. Üçüncü itiraz en ciddisi ve cevabı vakanın tanımında: bir saldırı vakası, yalnızca makine tarafından denetlenebilir bir başarı ölçütüyle sete girmeli — belirli bir alanın çıktıda görünmesi, belirli bir aracın çağrılması, belirli bir kaynağa erişilmesi gibi. Ölçütü öznel olan bulgular rapora kalıyor, sete girmiyor.

Sınırlar ve belirsizlik#

Bu analiz bir kırmızı takım metodolojisi değil ve setin kapsamının yeterliliğini ölçmenin bir yolunu sunmuyor.

• Kapsam yeterliliği ölçülemiyor: bilinmeyen saldırı yollarının sayısı bilinmiyor; geçen bir set güvenlik kanıtı değil.
• Vaka eskime ölçütü deneyimsel: bir vakanın ne kadar süre hiç geçmedikten sonra arşivlenmesi gerektiği kural değil tercih.
• İç risk gerçek: saldırı vakalarının kurum içinde yayılması ayrı bir yönetim gerektiriyor.
• Otomatik ölçütü olmayan bulgular kapsam dışında kalıyor: öznel zarar değerlendirmeleri bu hatta taşınamıyor.

Sonuç#

Kırmızı takımı bir tatbikat olarak kurmak, bulguların ömrünü yanlış varsayıyor. Dil modeli sistemlerinde saldırı yüzeyi modelin davranışına bağlı ve model davranışı sürümler arasında değişiyor; kapatılmış bir yol bir güncellemeyle yeniden açılabiliyor.

Doğru kurgu her bulguyu çalıştırılabilir bir vakaya çevirmek ve o vakayı sürekli koşan bir sete eklemek. Bunun iki getirisi var: geri açılmalar bir olaydan önce yakalanıyor ve her yeni kırmızı takım çalışması bilinen yolları yeniden denemekle değil, yeni yollar aramakla geçiyor. Birinci getiri güvenlik, ikincisi verimlilik — ve ikisi de tatbikat kurgusunda elde edilemiyor.

Ne yapmalı?#

1. 1Her bulguyu çalıştırılabilir vakaya çevirin

   Düz metin rapor aylar sonra yeniden denenmiyor. Vaka her koşuda bedavaya sınanıyor.

2. 2Makine tarafından denetlenebilir ölçüt yazın

   Belirli bir alanın çıktıda görünmesi, belirli bir aracın çağrılması gibi. Öznel ölçütlü bulgular rapora kalır.

3. 3Düzeltmenin türünü kaydedin

   Model davranışına dayanan savunma sürüme duyarlı; koddaki sert kontrol değil. Test önceliği bunu izliyor.

4. 4Türkçe ve karışık dilli varyantları ekleyin

   Filtreler çoğunlukla İngilizce sınanıyor; aynı saldırı Türkçe yazıldığında kaçabiliyor.

5. 5Sürüm değişiminde seti otomatik koşturun

   Sağlayıcı güncellemesi bir dağıtım olayı; regresyon hattı o kapıda çalışmalı.

6. 6Set erişimini daraltın

   Saldırı vakaları kod deposunda düz metin durmasın; koşu çıktıları içeriği açığa çıkarmasın.