Token ekonomisinin siber güvenlik süreçleri üzerindeki doğrudan etkisi

Kısa bir süre önce, “token ekonomisi” ve “Maliyet Tüketme Saldırısı” hakkında bir yazı yayınladık. Maliyet Tüketme Saldırısı, yapay zeka tokenlarının aşırı harcanmasını amaçlayan yeni bir DDoS saldırısı türüdür. Ancak güvenlik uzmanları, meslektaşlarının yapay zeka süreçlerini bu yeni tehditlere karşı korumaya başlamadan önce, bilgi güvenliği departmanının kendi çalışmalarının da bu tür bir saldırının hedefi haline gelebileceğini unutmamalıdır. Güvenlik ekipleri artık yapay zeka tabanlı çeşitli otomasyon türlerini aktif olarak test edip uygulamaya koydukları için, savunma sistemini felç etmeyi amaçlayan dış müdahale tehditleri, bu ekiplerin kendi süreçlerini ve teknolojilerini doğrudan etkilemektedir.

Elastic, “ajan tabanlı SOC” mimarisine bağlı olarak, bir ana bilgisayardan gelen tek bir uyarının önceliklendirilmesinin, son derece uzmanlaşmış ajanlardan oluşan bir grup için 0,69 $, ya da 14 farklı beceriye sahip genel amaçlı bir ajan için 3,42 $ maliyet getireceğini tahmin ediyor.

Ancak bu ortalamalar, çok geniş bir değişkenlik aralığını maskeler niteliktedir. Herhangi bir anda, basit bir uyarının (örneğin, bin token) ilk işlenmesi, milyonlarca günlük kaydı, API istemini ve diğer ilgili verilerin işlenmesini içeren, zincirleme bir araştırmaya dönüşebilir ve bu da birkaç dakika içinde milyonlarca tokena ulaşabilir.

Elastic, SOC’sinde Claude Sonnet 4.6 modelini kullandığını kendisi de kabul ediyor. Bu da hemen şu soruyu akla getiriyor: Bütçe tükendiğinde ya da modelin güvenlik filtreleri devreye girdiğinde ne olur? En kötü senaryoda şu durum ortaya çıkar: Yapay zeka destekli güvenlik operasyon merkezi (AI SOC), altyapıda yanal hareketlere benzeyen şüpheli olayları araştırmak üzere bir “ajanlar orkestrası” devreye sokar. Ajan, Anthropic API’ını çağırır, ancak departmanın aylık bütçesi tükenmiştir ve API hata mesajı verir. Araştırma durma noktasına gelir ve insanlar bunu yarım gün sonra öğrenir. Dahası, büyük bir yapay zeka sağlayıcısının sürekli değişen “güvenlik filtreleri”, SOC’nin taleplerini kötü niyetli olarak işaretlerse, bütçe tükenmeden bile aynı sonuç ortaya çıkabilir. Hugging Face’in, OpenAI tarafından altyapısına yapılan saldırıyı araştırma sürecinde yaşadığı deneyim bunun bir örneğidir.

Elbette, bir saldırganın böyle bir sonucun gerçekleşmesinden büyük çıkarı vardır. Kullanıcıların erişebildiği verilere (DNS TXT kayıtları, HTTP başlıkları, kod yorumları, dosya adları vb.) kötü niyetli komutlar ekleyerek, bu komutların bilgi güvenliği sistemleri tarafından işleneceği varsayımıyla kullanıcıların maliyetlerini doğrudan etkileyebilirler. Örneğin, GhostJacking saldırısı örneğinde, WAF günlükleri komut satırı enjeksiyonu için bir vektör görevi görürken, akademik bir araştırmada başka bir yöntem öne sürülmüştür. Araştırmacılar, LLM’nin güvenlik önlemlerine doğrudan saldırmayı başarmış ve bu sayede taleplerin gecikme süresini 148 kat, tüketilen token sayısını ise 63 kat artırmışlardır. Başka bir deyişle, sistem teorik olarak düzgün bir şekilde çalışmaya devam eder, ancak uyarıların işlenmesindeki gecikme süresi ve buna bağlı maliyetler önemli ölçüde artar.

Tehlikeli ve fark edilmeyen durum

Ajan tabanlı senaryolarda, bütçenin tükenmesi her zaman “talep limiti aşıldı” mesajı içeren açık bir hata olarak ortaya çıkmaz ve ilgili taraflara anında bir uyarı gönderilmez. Bazı yapılandırmalarda “gerilla” senaryoları ortaya çıkabilir. Modele yapılan bir talep zaman aşımına uğradığında, sistem otomatik olarak daha ucuz bir modele geçer; bunun sonucunda çıktıların kalitesi düşer ve alt ajanlar ve periyodik görevler yürütülmez hale gelir. Bu arada, güvenlik ekibi saatlerce her şeyin eskisi gibi işlediğine inanmaya devam edebilir.

Siber güvenlikte yapay zeka maliyetlerini nasıl kontrol edebiliriz?

Giderleri yönetme görevinin elbette sadece “aşırı harcamayı önlemekten” ibaret olmadığı açıktır. Sektör, SIEM’i hayata geçirirken çoktan bu tuzağa düşmüştü. Şirketler, toplanan telemetri verilerinin hacmine göre ödeme yapmak zorunda kaldıklarında, günlük toplama işlemlerini seçici bir şekilde (ve her zaman etkili olmayan bir şekilde) sınırlamaya başladılar. Sonuç olarak, sistemlerinde tespit edilemeyen kör noktalar oluştu. Aynı durum tokenlar için de ortaya çıkabilir, ancak daha hızlı ve daha geniş ölçekte. Kötü tasarlanmış bir maliyet azaltma ilkeği, araştırmaların kapsamını ve müdahale kalitesini olumsuz etkileyebilir. Ve böyle bir ilkenin bulunmaması durumunda, bir şeyleri durdurma kararı, sistem tasarım aşamasında mimar ya da CISO tarafından değil, sabah saat 3’te görev başında olan analist tarafından verilecektir. Sistem satıcısı tarafından ayarlanmış bir otomatik sınırlayıcı da olabilir.

Birkaç basit ilke, öngörülebilir maliyet aşımlarını önlemeye ve gerçekten öngörülemez durumları daha iyi yönetmeye yardımcı olabilir.

Yapay zeka modeline, standart bir sorguyla doğrulanabilecek hiçbir şeyi girmeyin. Tekrarlayan ve önceden bilinen her şey, eski usul yöntemle (kurallar ve veri sorguları ile) yönetilmelidir. Bunlar yapay zeka kullanılarak geliştirilebilir, ancak deterministik bir şekilde çalışmalıdır. Bu model, yalnızca belirsiz bir durumun değerlendirilmesinin gerçekten gerekli olduğu durumlarda kullanılmalıdır.

Sıkı limitler belirleyin ve bu limitler aşıldığında kullanıcıları kesin bir şekilde uyarın. Limitler; görev başına bir limit, günlük limit vb. olarak birleştirilmelidir. Limit aşımlarına ilişkin uyarılar, hem görev başındaki analistlere hem de sistemin genelinden sorumlu kişilere derhal iletilmelidir.

Bir limite ulaşıldığında ne olacağına önceden karar verin. Biraz kontrolü kaybetmek pahasına durup para biriktirmek mi, yoksa devam edip ödeme yapmak mı: Bu, bir olay meydana gelmeden önce alınması gereken bir karardır.

Ajanların yetkilerini ve kullanabilecekleri araçları sınırlayın. Sistemin erişebileceği eylemler ne kadar az olursa, dar kapsamlı bir görev de o kadar etkili çalışır, maliyetleri şişirme olasılığı o kadar azalır ve dışarıdan bir kişi tarafından “istismar edilme” ihtimali de o kadar azalır.

Dışarıdan gelen, güvenilirliği kanıtlanmamış verileri kesinlikle tarayın. Gelen talepler, sorgular, mesajlar ve yorumların yanı sıra, rastgele metin içerebilen çeşitli teknik alanlar (DNS kayıtları, HTTP başlıkları, dosya adları), sadece anlık enjeksiyona yol açmakla kalmaz, aynı zamanda iş yükünü kasıtlı olarak da artırabilir. Boyutlarını sınırlayın ve oluşturdukları yükü izleyin.

Dış hizmet sağlayıcılarının neden olabileceği hizmet kesintilerini önlemek ve kuruluşunuzun verileri üzerinde tam kontrol sağlamak için, en azından bilgi güvenliği ihtiyaçları açısından şirket içi olarak kurulan yerel modelleri kullanma olasılığını değerlendirin. Bu modeller en son teknoloji ürünü olmasa da, dar kapsamlı uzmanlık alanları ve şirket verileriyle yapılan ince ayarları sayesinde, beklenmedik arızalar yaşanmadan tatmin edici bir performans sergileyecektir.

Daha karmaşık bir mimaride, büyük dil modellerinin (LLM) kullanımı birkaç düzeye ayrılabilir. İlk savunma hattı (yönlendirme, gürültü filtreleme, veri zenginleştirme) kompakt şirket içi modeller tarafından yürütülmektedir. Bu, bütçedeki dalgalanmayı önemli ölçüde azaltır. İkinci düzey; olayları birbirine bağlamak, hipotezleri test etmek ve bir olayın genel resmini ortaya çıkarmak gibi asıl işi üstlenen geniş kapsamlı bir yerel modelden meydana gelirgyz . Ayrıca talep başına faturalandırılmaz, ancak işleme kapasitesi sınırlıdır; bu nedenle, bütçe aşımları yerine aşırı yük ve olay kuyrukları ortaya çıkabilir. Yalnızca münferit ve gerçekten zor vakalar, tercihen bir insan analistin açık onayıyla, gelişmiş bulut tabanlı modellere yönlendirilir. Bu sistemde değişken maliyetler devam eder, ancak bunlar az sayıda durumla sınırlıdır ve her biri, gece boyunca çalışan bir komut dosyasının yan etkisi olmaktan ziyade bilinçli bir tercihi temsil eder.

Esasen, tüm bunlar klasik çok katmanlı SOC modelini yansıtmaktadır (birinci katmanda filtreleme, üçüncü katmanda ise araştırma yapılır); tek fark, bu rollerin insanlar yerine modeller tarafından üstlenilmesidir.