AI Incident Response Playbook
LLM Olaylarında Saat-Saat Müdahale

AI Incident Response Nedir?

Incident response, bir güvenlik ihlali tespit edildiğinde uygulanan yapılandırılmış süreçtir. Endüstri standardı altı aşamadan oluşan bir döngüye dayanır: hazırlık, tanımlama, sınırlama, ortadan kaldırma, kurtarma ve öğrenilen dersler. NIST SP 800-61 ve SANS çerçeveleri aynı döngüyü farklı isimlerle anlatır; isim ne olursa olsun mantık aynıdır.

AI incident response, bu çerçevenin yapay zeka ve agent tabanlı sistemler için uyarlanmış halidir. Döngünün omurgası aynı kalır; ancak içerik tipi, adli kanıtın doğası, sınırlama aksiyonları ve "kökten çözüm" kavramının anlamı tümüyle değişir. Klasik bir IR senaryosunda "etkilenen sunucuyu izole et" denir; yapay zeka senaryosunda ise "etkilenen prompt akışını sonlandır, sistem promptunu rotasyona al, RAG belgelerini gözden geçir" denir. Aynı disiplin, farklı bir teknik gerçeklik üzerinde uygulanır.

Hangi Olaylar Playbook'u Tetikler?

Bir AI SOC'ta hangi tür olayların müdahale akışını başlattığını bilmek, hazırlığın temelidir. En sık karşılaşılan olay sınıfları aşağıdaki tabloda özetlenmiştir; her birinin kendine özgü bir belirti seti ve tipik kaynağı vardır.

İlk Bir Saat: Sınırlama

Bir alarm geldi; AI SOC analisti playbook'u açtı. Bu saatin tek hedefi açık: kanamayı durdurmak ve kanıtı bozulmadan korumak. Akış birbirini takip eden birkaç adımdan oluşur.

İlk iş triajdır; gelen alarmın gerçekten bir tehdit mi yoksa yanlış pozitif mi olduğu prompt-cevap zincirine ve bileşik skora bakılarak doğrulanır. Doğrulama tamamlandığında etkilenen oturum hemen kesilir; saldırgan oturumu karantinaya alınır, o oturumdan gelen yeni LLM çağrıları artık modele iletilmez. Aynı saldırı kalıbının başka kullanıcılarda da görülmesi ihtimaline karşı sıkı reddetme kuralı geçici olarak tüm tenant'lara uygulanır; bu hareket kampanya senaryosuna karşı bir tampon görevi görür.

Sistem promptu sızıntısı şüphesi varsa önceden hazırlanmış yedek sistem promptu devreye alınır; orijinali rotasyona girer. Model çıktısının bir araca, bir e-postaya ya da bir ödeme akışına bağlandığı senaryolarda bu arka uç sistemler de geçici olarak dondurulur; sızıntının uzantısının önüne geçilir. Tüm bu sırada adli görüntü alma sessiz biçimde devam eder; etkilenen kullanıcının son hareketleri, RAG sorguları ve araç çağrı zinciri ayrı bir kasaya kopyalanır, çünkü loglar rotasyona uğradığında kanıt kaybedilir. Son olarak CISO bilgilendirilir ve KVKK saatinin başlayıp başlamadığına dair ilk değerlendirme yapılır; kişisel veri sızıntısı doğruluyorsa cevap büyük olasılıkla evettir.

Bu saatin sonunda hedeflenen tablo şudur: olay sınırlandı, yeni etkilenecek kullanıcı kalmadı, kanıt güvende.

İlk Yirmi Dört Saat: Adli Toplama ve Kapsam

Sınırlama bittikten sonra ekibin önündeki soru değişir. Artık panik değil, soğukkanlı analiz zamanıdır; ne oldu, kim etkilendi, savunma neden geçirdi?

İlk adım olayı zaman çizelgesi üzerinde yeniden kurmaktır. İlk anomali sinyalinden itibaren tüm olaylar kronolojik biçimde dizilir; hangi prompt geldi, hangi RAG belgesi çekildi, hangi araç tetiklendi, model hangi cevabı verdi? Bu yeniden kurulum, sonraki tüm analizlerin temel girdisidir. Ardından saldırı kalıbı sınıflandırılır: rol oyunu (roleplay) mu, çeviri bahanesi mi, dolaylı enjeksiyon mu? Olay OWASP LLM Top 10 kategorilerinden hangisine düşüyor?

Sonra kapsam analizi gelir; aynı saldırı kalıbı son haftalarda başka kullanıcılarda da göründü mü, geriye dönük log taraması yapılır. Buna paralel olarak etkilenen veri envanteri çıkarılır: hangi kişisel veri tipleri sızdı, kaç kullanıcıyı etkiliyor, çıktı hangi sistemlere aktarıldı? Bu envanter olmadan KVKK bildirimi dolduramazsınız.

Teknik ekibin paralel olarak yürüttüğü bir başka iş kök neden hipotezini netleştirmektir; guardrail neden bu kalıbı yakalamadı, tespit kuralı neden geçirdi, sistem promptu hangi noktada zayıf kaldı? Bu hipoteze dayanılarak geçici azaltma önlemleri devreye alınır; kalıcı düzeltme henüz hazır değildir ama aynı saldırının tekrarlanmasını zorlaştıran ek kurallar ve eşik sıkılaştırmaları üretim ortamına alınır. Aynı saat içinde iletişim ekipleriyle koordinasyon başlar; hukuk, halkla ilişkiler ve müşteri başarı birimleri haberdar edilir, gerekirse müşteri bildirim taslakları hazırlanır.

Yetmiş İki Saat: KVKK Bildirimi

KVKK'ya göre kişisel veri ihlali tespit edildiğinde, veri sorumlusunun en kısa sürede ve makul gerekçeler dışında 72 saat içinde Kişisel Verileri Koruma Kurumu'na bildirim yapması zorunludur. Sayaç şüpheyle değil, doğrulanmış tespit anıyla başlar.

Bu süre içinde önce ihlal kapsamının kesinleştirilmesi gerekir; gerçekten kişisel veri sızdı mı, hangi kayıtlar etkilendi, şüpheli ama henüz doğrulanmamış vakalar nasıl ayrıştırılıyor? Kapsam netleştikten sonra VERBİS bildirim formu doldurulur. Form, ihlal tarihini, türünü, etkilenen veri kategorilerini, kişi sayısını ve alınan tedbirleri bekler.

Bazı durumlarda ilgili kişilere de bildirim yapmak zorunludur; özellikle Madde 6 kapsamında özel nitelikli veri sızıntısı olduysa bu yükümlülük genellikle doğar. Tüm bu süreç hukuk ekibiyle koordinasyon içinde yürütülmelidir; zamanında ve eksiksiz bir bildirim, sonradan oluşabilecek idari yaptırımları azaltan en önemli faktördür. AB pazarına da hizmet veren kurumlar için EU AI Act yüksek riskli sistemler bağlamında ayrı bir olay raporlama yükümlülüğü getirir; bu iki süreç paralel yürütülmelidir.

Kökten Çözüm ve Üretime Dönüş

Kanıt korundu, kapsam çıkarıldı, bildirim yapıldı. Sıra kalıcı düzeltmeye geldi. Bu aşamada geçici azaltmaların yerini kurumsal hafızada yaşayacak değişiklikler alır.

Guardrail kuralı geçici olarak değil versiyonlanmış halde üretime taşınır; aynı saldırı bir daha geldiğinde otomatik olarak yakalanır. Tespit tarafında ise yeni saldırı kalıbı için Sigma benzeri bir kural AI SOC kural setine eklenir. Eğer olay sistem promptu sızıntısıysa promptun direnç katmanları sertleştirilir; sınır çakıştırma, rol kilitleme gibi teknikler güçlendirilir. RAG zehirlenmesi söz konusuysa zararlı belge silinir ve etkilenen embedding'ler yeniden hesaplanır. Eğer agent hijack'i yaşandıysa araç izin listesi daraltılır; gerekçesi olmayan araç erişimleri kaldırılır.

Üretime dönüş genellikle dereceli yapılır. Önce iç kullanıcılar üzerinde dönüş yapılır, ardından sınırlı bir müşteri yüzdesinde test edilir, son olarak tam trafik açılır. Bu süre boyunca aynı saldırı kalıbının geri dönüp dönmediği yakından izlenir. Etkilenen müşterilere durum güncellemesi iletilir ve gerekiyorsa hizmet kredisi sunulur.

Öğrenilen Dersler

Olay kapandıktan bir-iki hafta sonra yapılan retrospektif toplantı, döngünün en değerli adımıdır. Hedef hata aramak değil; aynı olayın bir daha yaşanmayacağından emin olmak ve playbook'u somut biçimde iyileştirmektir.

Sorulması gereken sorular her zaman aynı temalardan beslenir. Olayın tespit edilmesiyle sınırlama arasındaki süre ne kadardı, bunu yarıya indirmenin somut bir yolu var mı? Hangi telemetri eksikti, hangi log alanı olsaydı bu olayı saatler önce yakalardık? Guardrail tarafında hangi kural eksikti ve bu kuralı eklemek başka yanlış pozitif üretir mi? Playbook hangi adımda durakladı, hangi adımda gerçeklikten koptu? CISO, hukuk ve halkla ilişkiler arasındaki iletişim akışı sorunsuz işledi mi? KVKK bildirim süresine yetişildi mi, yetişilmediyse neden? Ve son olarak, bu olay regresyon test setine kalıcı olarak eklendi mi; yani aynı saldırı yarın geldiğinde sistem otomatik yakalayacak mı?

Bu toplantının çıktısı genellikle güncellenmiş bir playbook, yeni tespit kuralları, regresyon test setine eklenen senaryolar ve gerekiyorsa mimari iyileştirmeleri kapsayan bir görev listesi olur.

Sık Yapılan Hatalar

Olay müdahale sürecinde en sık karşılaşılan tuzakların başında playbook'u olay anında yazmaya çalışmak gelir. Hazırlık aşaması atlanırsa diğer beş aşama düzgün işlemez; çünkü ekibin bir krizin ortasında öğrenmesi beklenemez. Bir başka klasik hata KVKK saatini başlatmaktan korkmaktır; şüpheli vakayı "henüz kesin değil" diyerek uzatmak, doğrulandığında 72 saatlik sınırın aşılmasına yol açar.

Adli görüntü almayı ihmal etmek büyük bir kayıptır; loglar rotasyona uğrar ve sonradan ne olduğunu kanıtlamak imkânsızlaşır. Üretim ortamında sistem promptunu panik halinde değiştirmek de tehlikelidir; versiyonsuz ve yedeksiz bir değişiklik geri dönüşü zorlaştırır. Promptlar kod gibi yönetilmeli, sertifikalandırılmalıdır.

Bir olayı tek başına yaşanmış izole bir vaka olarak değerlendirmek sıkça düşülen başka bir tuzaktır; aslında bir kampanyanın parçası olabilir ve geriye dönük log taraması atlanmamalıdır. Öğrenilen dersler toplantısını ihmal etmek, olayın aylar sonra tekrar yaşanmasının en büyük sebebidir. Son olarak olaya yalnızca teknik bir mesele olarak yaklaşmak ciddi bir hatadır; hukuk, halkla ilişkiler ve müşteri başarı ekipleri olayın ilk saatlerinden itibaren akışın içinde olmalıdır.

Sonuç

Yapay zeka incident response süreci, klasik IR'nin yepyeni bir biçimi değil; aynı disiplinin yeni bir teknik gerçekliğe taşınmış halidir. Hazırlık-tanımlama-sınırlama-ortadan kaldırma-kurtarma-dersler döngüsünün omurgası korunur; ama içerik tipi, kanıt mimarisi ve müdahale aksiyonları değişir. İlk bir saat sınırlamaya, ilk yirmi dört saat adli toplamaya ve kapsam analizine, yetmiş iki saat ise KVKK bildirim eşiğine ayrılır.

AltaySec olarak kurumsal müşterilere AI IR playbook'ları, masa üstü tatbikat senaryoları ve AI SOC entegrasyonlu kural setleri üzerine çalışıyoruz. Bir sonraki yazıda playbook'un hukuki çerçevesini daha geniş bir perspektifte ele alan EU AI Act Uyum Rehberi'ne geçeceğiz.