Net güvenlik röportajında bu yardımda Nottingham Üniversitesi Doçent Michael Pound, LLMS ile ilişkili siber güvenlik riskleri hakkındaki görüşlerini paylaşıyor. LLM’leri iş operasyonlarına entegre ederken ortak örgütsel hataları ve hassas verilerin güvence altına alınması için gerekli önlemleri tartışmaktadır.
LLM kullanımı söz konusu olduğunda, CISO’lar ve güvenlik ekipleri arasında anlayış veya hazırlıktaki en büyük boşlukları nerede görüyorsunuz?
Birçok güvenlik uzmanı – oldukça makul – LLM’lerin altında yatan makine öğrenmesinde iyi bilgili değildir. Geçmiş teknolojilerle bu çok önemli değildi, ancak LLMS bir bakışta o kadar güçlü görünüyor ki, bizi kandırılamayacaklarını düşünmek için yanıltabilir. Gerçek dünyada kötü bir şekilde kırılan kötü düşünülmüş sistemler inşa etmek için acele edebiliriz. Belki de en önemli şey, LLM’lerin en üretken yapay zekasının olasılıklı olduğunu hatırlamaktır – rastgelelik ile hareket eder. Bu, istediğiniz şeyi yapma şansı olduğu anlamına gelir, ancak şans nadiren%100’dür.
AI çözümleri sunan şirketler, bu modelleri kıramayacakları bir şekilde geliştirdiklerini önermek için AI korumaları ve hizalama hakkında konuşacaklar. Gerçekte bunun anlamı, bir şirketin LLM’yi bir dizi kendi hazırlanmış kötü niyetli istemlerini reddetmesi için eğitmeye çalıştığıdır. Bu, yolsuz davranış şansını küçük bir değere düşürür, ancak sıfıra değil. LLM’nin yeni ve görünmeyen bir istemi reddetip reddetmediği, gerçekleşene kadar kesin olarak bilemeyeceğimiz bir şeydir. Birçok örnek, bir LLM’yi kötü bir şey yapmaya ikna etmenin yeni ve şaşırtıcı yollarından.
Özellikle hassas veya tescilli bilgilerle ilgili olarak, kuruluşların verileri LLM’lere beslerken en yaygın hatalar nelerdir?
Kısa vadede şirketler bu araçları dahili olarak kimin kullandığını, hangi araçları ve nasıl kullanıldığını belirlemelidir. Birçok son kullanıcı, bu modellere koydukları sorguların buluta yüklendiğinin farkında değildir ve bazı hizmetlerde bunlar eğitim verilerine girebilir. Sonuçları gerçekten dikkate almadan gizli müşteri veya şirket bilgilerini yüklemek kolaydır. Son modeller, özel verilerinizi öğrenmek ve mutlu bir şekilde yeni birine göndermek için yeterli parametreye sahiptir. E -posta veya takvim zamanlamasını işleyenler gibi verimlilik uygulamaları bu bilgilere tanım gereği erişebilir. Nereye gidiyor? Bu araçlar için ücretli lisanslar genellikle daha güçlü kullanım kontrollerine ve anlaşmalara sahiptir – bunlar araştırmaya değer.
Tarihi SQL saldırılarına benzer şekilde, kontrolsüz kullanıcı girişine çok dikkat etmelisiniz. Testte bir LLM’ye 100 kez aynı soruyu sorabilirsiniz, cevaplar farklı ama tutarlıdır. Yine de serbest bırakıldıktan sonra, birisi bir soru biraz farklı bir şekilde sorabilir veya daha kötüsü, bir LLM’yi kötü niyetli eylemlere kasıtlı olarak yönlendirebilir. Geleneksel kodla bunun için kontrol edebilirsiniz, “Giriş bu titiz formatla eşleşmiyorsa, reddet”, ancak LLMS ile korunanları atlatan geçerli istemler yazmak kolay olabilir. Sorun aslında SQL’den çok daha kötü. SQL enjeksiyonu ile, kötüye kullanımı önlemek için giriş sanitasyonu, parametrelendirilmiş sorgular ve diğer mekanizmalarda inşa edebilirsiniz, bu LLM’ler için imkansızdır. Dil modelleri, kullandıkları verilere karşı bir istemi kavramına sahip değildir, hepsi aynıdır. Bu aynı zamanda, bir kullanıcının sağlayabileceği yüklenen belgelerin veya diğer dosyaların yalnızca doğrudan metin girişi değil, bir kaynak veya kötü amaçlı istemler olduğu anlamına gelir.
LLMS’nin araçlara erişim sağlandığı için risk artar – diğer kodlara ve API’lara bağlantılar. Bir LLM web istekleri yapabilirse, Markdown veya diğer URL’ler aracılığıyla verileri ekleme şansı vardır. Bir LLM özel verilerinizden herhangi birine erişebiliyorsa, risk artar.
Ne tür savunmalar veya hafifletmeler şu anda LLM manipülasyon riskini çekişmeli girdilerle azaltmada en etkilidir?
Modelleri, kötü niyetli istemleri önlemek için eğitmeye çalışırken, birisi önlemleri önlemek için farklı bir strateji geliştirmeden önce kısa bir süre sürer. Savunmanız, LLM’nin ne yapması gerektiğine bağlı olacaktır. Belgeleri özetlemek veya veri almak için kullanmayı umuyorsanız, kötü niyetli istemler içermediklerinden emin olmak için hangi belgeleri okuyabileceğini dikkatlice kontrol etmek istersiniz.
Yapay zekanız doğrudan kullanıcı girişine yanıt veriyorsa – örneğin müşterilerinize, bir noktada birisinin önlemleri test etmesi kaçınılmazdır. LLM’lerinizi nasıl tepki verdiklerini görmek için düzenli olarak test etmelisiniz, sorunlu istemleri tespit etmek ve ayıklamak için başka işlevleri de kullanabilirsiniz. Bazı açılardan SQL enjeksiyon kuralları hala geçerlidir-en az ayrıcalık ve rol temelli erişim kontrolü prensibi. AI sisteminizi, LLM’nin denemesine rağmen hasar veremeyeceği şekilde ayarlayın.
LLM’leri iş iş akışlarına güvenli bir şekilde entegre etmek için hangi çerçeveleri veya yönergeleri önerirsiniz?
Her ne kadar uzun zamandır LLM’ler hakkında konuşuyoruz gibi görünse de, gerçekten sadece birkaç yaşında. Sistemler yenidir, popüler kütüphaneler düzenli olarak değişir. İyi seçenekler şu anda Haystack, Langchain ve Lama-Index’dir. Bunların çoğu, veri gizliliği konusunda endişeleniyorsanız özellikle yararlı olan kendi yerel modellerinizi çalıştırma fikrine dayanmaktadır.
En büyük modeller büyük kaynaklar gerektirir, ancak en mütevazı modeller standart donanımda harika performans sunar. Modelleri yerel olarak test etmek istiyorsanız, Ollama’yı deneyin. Çıktılarını daha hassas bir şekilde kontrol etmenin çok etkili bir yolu olabilecek modelleri yeniden eğitmek istiyorsanız, hoşnutsuzluğa bir göz atın. Copilot, Chatgpt ve Antropik Claude gibi ticari ürünler de daha yüksek bir maliyetle güvenilirdir.
LLM’ler altyapıya daha derin bir şekilde entegre hale geldikçe, hangi uzun vadeli veya sistemik siber güvenlik endişeleri bekleyebiliriz?
LLM’leri gittikçe daha fazla sisteme yerleştirdiğimiz bir dönemdeyiz ve insanlar bu modellerin normal yazılım geliştirmeden nasıl farklı olduklarına alışık değil. Biraz zamanın işe yaramadığı veya beklenmedik bir şey çıktısı yazma kodu görüntüleme. Zamanın% 99,999’unu doğru olan neredeyse mükemmel bir LLM bile, her 1000 çağrı bir kez matematiksel olarak başarısız olacak. Rahat olmayan LLM’lerin sağlam sistemlerde kullanılabilmesini sağlamak için nasıl yazılım oluşturduğumuzu tamamen yeniden düşünmemiz gerekiyor. Tıpkı SQL enjeksiyon boşluklarını kapatmak için yıllar geçirdiğimiz gibi, 2015 yılı kadar büyük ihlallerle, beklenmedik bir istemin bir LLM’nin felaket yollarında yanlış davranmasına nasıl neden olduğunu duymak için uzun süre harcayacağız.