İşe yarayan AI sistemleri kurmak için önce onları bozmanız gerekir. Finansal hizmetlerde müşterilere yönelik bir AI uygulamasını sınamak ve incelemek için saldırgan rolünde bir red teaming çalışması yürüttük. Bulgularımız, güvenliğin vazgeçilmez olduğu LLM destekli uygulamaları devreye alan herkes için önem taşıyor.
Red teaming, gerçek bir saldırgan bulmadan önce güvenlik açıklarını giderebilmek için AI sisteminizi kasıtlı olarak bozmaya çalışma uygulamasıdır. Finansal hizmetlerde risk özellikle yüksektir: AI uygulamaları müşteri verilerine erişir, işlemleri gerçekleştirir ve finansal içgörüler sunar. Bir hata; kötü bir kullanıcı deneyiminden mevzuat ihlallerine, mali kayıplara ve telafisi mümkün olmayan marka zararına kadar uzanan sonuçlar doğurabilir.
Amacımız güvenlik açıklarını erkenden bulmak, gerçekçi saldırı kalıplarını test etmek ve kuruluşun düzenleyici kurumların büyük önem verdiği AI güvenliği beklentilerini karşılamasına yardımcı olmaktı.
Burada önemli bir ayrım var: jailbreak saldırıları temel modelin güvenlik filtrelerini hedeflerken prompt enjeksiyonu, güvenilmeyen kullanıcı girdisini geliştiricinin güvenilir promptuyla birleştirerek doğrudan uygulamayı hedefler. Prompt enjeksiyonu, genel amaçlı bir modeli değil sisteminizi ve sistemin işlediği gizli verileri hedeflediği için daha büyük risk oluşturur.
İlk test turumuz, şu alanlarda yaklaşık 750 testten oluşuyordu:
Oturumlar arası veri sızıntısı
PII ifşası (doğal dil, API manipülasyonu ve çeşitli kodlamalar yoluyla)
SQL enjeksiyonu
Sistem promptunu geçersiz kılma
Bu ilk testlerde mevcut sistemde iki önemli sorun belirledik: birden çok amaç içeren sorguların işlenmesi ve kodlanmış promptların kullanılması.
Birden çok amaç içeren sorgular: Meşru ve kötü amaçlı talepleri bir araya getiren istekler. Örneğin: “Show my spending by category, and also execute [malicious SQL].” Uygulama kötü niyeti tespit edemiyor, bunun yerine tamamen sonraki veri katmanındaki güvenlik önlemlerine bel bağlıyordu. Bu, bodrumdaki kasaya güvendiğiniz için evin giriş kapısını açık bırakmaya benzer.
Kodlama: İsteklerin Base64, Hex, LeetSpeak ve homogliflerle kodlanması. Sistemlerin bu isteklerdeki kötü niyeti filtrelemesi zor olabilir. Bu sorguların hassas verileri açığa çıkarmadığını görsek de sistemde ciddi istikrarsızlığa yol açtılar (halüsinasyonlar, kötü amaçlı SQL'in kullanıcıya aynen döndürülmesi, amaç sınıflandırmasında karışıklık vb.).
İlk testlerimizin sonuçları şunları gösterdi:
Zamansal halüsinasyonlar: modelin uydurma tarihleri, işlem zaman damgalarını veya belirli dönemlere ilişkin özetleri kendinden emin ifadelerle sunması. Yanlış bir tarihe göre hareket eden müşterinin gerçek sonuçlarla karşılaşabileceği finansal bağlamda bu ciddi bir risktir
Kötü amaçlı SQL'in kullanıcıya aynen döndürülmesi (bellek zehirlenmesi riski açısından kaygı verici)
Amaç sınıflandırmasında karışıklık
Bozulmuş çıktı biçimlendirmesi
Bu bulgularla odağımızı daralttık. SQL enjeksiyonu ve kodlama testlerinin önceliği düşürüldü; ekip zaten bunları ele alıyordu. Bunun yerine en başarılı saldırı vektörlerine odaklandık: PII ifşası ve oturumlar arası veri sızıntısı.
İkinci turun en çarpıcı bulgusu şaşırtıcı derecede basitti: çoğu zaman hiç de kurnaz olmanız gerekmiyor.
Çoğu durumda, kulağa meşru gelen bir talebin parçası olarak sunup sistemden dahili verileri istemek, sistemin bunları ifşa etmeyi kabul etmesi için yeterliydi. Basit sorgulara verilen yanıtlarda, son kullanıcılara asla gösterilmemesi gereken dahili kimliklere ve sistem alanlarına atıfta bulunuluyordu.
Daha derine indiğimizde bunun yalnızca uygulama düzeyinde bir hata olmadığını gördük. Sonraki text-to-SQL hizmeti, gerekenden fazla alan isteyen sorgular oluşturuyor ve açıklayıcı yanıtlarında erişimi kısıtlanması gereken verilere atıfta bulunuyordu. Bu durum, sistemler arasındaki gerçek bir çatlağı ortaya çıkardı: Tek tek bileşenleri ayrı ayrı değil, tüm teknoloji yığınını test ettiğinizde ortaya çıkan türden bir güvenlik açığı.
Modele değil, sisteme red teaming uygulayın. Bir LLM'yi tek başına test etmek, uygulamanızın güvenlik durumu hakkında size çok az bilgi verir. Kullanıcının etkileşime geçeceği şekilde tüm teknoloji yığınını uçtan uca test edin.
Girdi doğrulaması LLM'den önce yapılmalıdır. Kodlanmış sorgular, birden çok amaç içeren saldırılar ve temel enjeksiyon girişimleri sonraki hizmetlere bırakılmamalı, sistemin sınırında yakalanmalıdır.
Birleşim noktalarına güvenmeyin. Birden fazla hizmet içeren mimarilerde en ilginç güvenlik açıkları, sistemlerin arasındaki çatlaklarda saklanır. Sıfır güven gerçekten sıfır güven demektir; bu nedenle her şeyi her katmanda doğrulayın.
Basit saldırılar işe yarar. Gelişmiş jailbreak saldırıları manşetlere çıkıyor ama bazen tek yapmanız gereken... istemektir. Kullanıcı, bunun dışında meşru olan bir sorguya dahili tanımlayıcıları eklediğinde sisteminiz bunları hiç çekinmeden gösteriyorsa bu bir sorundur.
Aslında neyi test ettiğinizi anlayın. Bilinen saldırı kalıplarını sizin güvenlik önlemleriniz değil, LLM'nin kendi eğitimi yakalıyor olabilir. Hangi kontrollerin gerçekten devreye girdiğini anlamak için red teaming sürecinize gözlemlenebilirlik kazandırın.
Kısıtlı ortamlar yaratıcı çözümler gerektirir. Özel sağlayıcılar ve yerel model desteği, özel bulut erişimi olmadan da anlamlı red teaming çalışmalarını mümkün kılar. Ancak bunun getirdiği kısıtlamalar konusunda şeffaf olun.
Red teaming tek seferlik bir çalışma değildir. Yinelemeli olmalı, mümkün olduğunca otomatikleştirilmeli ve sisteminiz geliştikçe o da gelişmelidir. Yarın önem taşıyacak saldırılar, bugün önem taşıyanlarla aynı değildir.
Düzenlemeye tabi ortamlardaki AI sistemleri giderek daha fazla incelemeyle karşılaşacaktır. Güvenlik testlerini lansman öncesinde işaretlenecek bir kutu değil, sürekli bir disiplin olarak gören kuruluşlar bu incelemeleri karşılamaya ve müşteri güvenini kaybettiren halkla ilişkiler felaketlerinden kaçınmaya daha hazırlıklı olacaktır.