SOAR Projelerinde Saha Perspektifi: Otomasyonun Rolü

SOAR projeleri çoğu kurumda benzer bir tabloyla karşılaşır: sistem kurulur, entegrasyonlar tamamlanır, playbook’lar yazılır. Teknik olarak her şey çalışır durumdadır. Ancak operasyon tarafında beklenen değişim gerçekleşmez. Analist hâlâ manuel ilerler, otomasyon sistemde var olur ama sürecin merkezine yerleşmez.

Bu durum çoğu zaman teknik bir eksiklik olarak değerlendirilir. Oysa sahadaki deneyim bunun aksini gösterir. SOAR projelerinde sorun genellikle otomasyonun varlığı değil; nasıl konumlandırıldığı, hangi beklentiyle başlatıldığı ve operasyonun içine nasıl entegre edildiğidir.

Natica olarak yürüttüğümüz projelerde edindiğimiz saha deneyimleri doğrultusunda, SOAR projelerinin en sık zorlandığı alanları ve oluşan yanlış beklentileri bu yazıda ele alıyoruz.

Yanlış Başlangıç

SOAR projeleri bazen yanlış bir varsayımla başlayabilir. Otomasyonun doğrudan insan ihtiyacını azaltacağı düşünülür ve proje bu beklenti üzerinden şekillenir.

"Otomasyon daha az analist gerektirir."

Bu yaklaşım sahada karşılık bulmaz. Çünkü SOAR, analistin yerini almak üzere değil, tekrar eden işleri azaltmak ve analistin odağını daha kritik noktalara kaydırmak için konumlandırılır.

"SOAR, analistin işini devralmaz ve kadro küçültme aracı değildir. Asıl işlevi, mevcut analist kapasitesini daha yüksek değerli işlere yönlendirmektir."

Bu fark doğru anlaşılmadığında, proje yanlış başarı kriterleriyle ölçülür ve teknik olarak doğru ilerlese bile beklenti–gerçeklik uyumsuzluğu oluşur.

Süreç Sorunu

SOAR’ın başarısı doğrudan süreç olgunluğuna bağlıdır. Süreçlerin net olmadığı bir ortamda otomasyonun başarılı olması mümkün değildir.

"Phishing geldiğinde ne yapıyorsunuz? diye sorduğumda her analistin farklı bir şey söylemesi, SOAR projesinin erken bir uyarısıdır."

Bu durum, organizasyon içinde ortak bir aksiyon modelinin bulunmadığını gösterir. SOAR yeni bir süreç üretmez. Mevcut olanı hızlandırır.

"SOAR, iyi tanımlanmış bir aksiyon planını hızlandırır ama olmayan süreci icat edemez."

Bu nedenle otomasyonun temeli teknolojiden önce süreçlerin net şekilde tanımlanmış olmasıdır.

Bağlam Eksikliği

SOAR’ın en kritik kırılma noktalarından biri, teknik doğruluk ile operasyonel doğruluk arasındaki farktır. Bir playbook kurallara göre doğru çalışabilir, ancak bağlam eksikliği nedeniyle yanlış sonuç üretebilir.

Otomatik IP bloklama veya hesap kilitleme senaryolarında sistem doğru sinyali işler ve aksiyonu tetikler. Ancak bu aksiyon her zaman doğru hedefi etkilemez.

"Test ekibinin IP'si veya hesabı playbook tarafından engelleniyor."

Bu noktada problem teknoloji değil, bağlamın modele yansıtılmamış olmasıdır.

Güven Eksikliği

SOAR projelerinde teknik doğruluk tek başına yeterli değildir. Otomasyonun gerçekten kullanılabilmesi için analistin ona güvenmesi gerekir.

"Playbook bir kez yanlış/eksik aksiyon aldığında analist bir daha işi ona bırakmayıp, aksiyonu manuel kontrol etmeyi tercih edebiliyor."

Bu davranış zamanla istisna olmaktan çıkar ve standart hale gelir. Playbook’un tek bir hatası bile otomasyonun sistemde kalıp operasyon dışında bırakılmasına neden olabilir. Bu nedenle başarılı SOAR projeleri tam otomasyonla değil, kontrollü geçişle başlar.

Gürültü Problemi

SOAR, mevcut problemi ortadan kaldırmaz; çoğu zaman hızlandırır. Özellikle veri kalitesi düşük ortamlarda bu durum doğrudan operasyona yansır.

"Ne kadar false positive alarm, o kadar gereksiz playbook tetiklenmesi."

Bu durum analistin iş yükünü azaltmak yerine artırır ve alarm yorgunluğuna neden olur.

"FP kaynaklı playbook gürültüsü içinde gerçek bir olay gözden kaçabiliyor."

Bu nedenle otomasyon veri kalitesinden bağımsız düşünülemez ve SIEM kalitesinin üzerine inşa edilmelidir.

"SOAR, SIEM kalitesinin üzerine bina edilmeli; altına değil."

Otomasyonun Sınırları

Her SOC süreci otomasyon için uygun değildir. Özellikle belirsizliğin yüksek olduğu senaryolar otomasyonun sınırlarını ortaya çıkarır.

"Zero-day response en net örnek, ortada tanımlı bir akış yok çünkü senaryo daha önce görülmemiş."

Benzer şekilde bağlama ve organizasyonel dinamiklere bağlı süreçler de otomasyona dirençlidir.

"Insider threat soruşturmaları ve kritik varlıklarda aksiyon alma da zor; çünkü bu süreçler kuruma özel bağlam, sezgi ve bazen politik değerlendirme gerektiriyor."

Bu nedenle otomasyonun en yüksek değer ürettiği alanlar, tekrar eden ve açık şekilde tanımlanmış süreçlerdir.

Entegrasyon Karmaşası

SOAR projeleri büyüdükçe entegrasyon sayısı artar ve her entegrasyon yeni bir bağımlılık yaratır.

"Token expire oldu, API değişti, servis bir an down oldu vb. Playbook error alabiliyor."

Zamanla sistem karmaşıklaşır ve bağımlılıkların takibi zorlaşır. Test eksikliği olduğunda hatalar ancak gerçek olaylar sırasında fark edilir.

Değer Ölçümü

SOAR’ın gerçekten değer üretip üretmediğini anlamak için yalnızca hız metriklerine bakmak yeterli değildir.

"Bu playbook olmasaydı analist bu adımı atlayabilir miydi?"

Bu soru, otomasyonun gerçek katkısını ortaya koyar.

Doğru Başlangıç

Başarılı SOAR projeleri büyük ve kapsamlı kurulumlarla değil, kontrollü ve hedefli başlangıçlarla ilerler.

"Önce hiçbir tool'a dokunmuyorum."

İlk odak noktası araç değil, mevcut operasyonun anlaşılmasıdır.

"Asıl mesele gürültünün tespiti ve azaltılması."

Sonrasında doğru başlangıç senaryosu seçilir.

"En yüksek hacimli, en net tanımlı, en az riskli senaryo seçilir."

Bu yaklaşım, otomasyonun kontrollü büyümesini ve ölçülebilir değer üretmesini sağlar.

Operasyon Gerçeği

SOAR projelerinde asıl belirleyici teknik doğruluk değil, operasyonel karşılıktır. Bir sistemin çalışıyor olması yeterli değildir; o sistemin gerçekten kullanılıyor olması gerekir.

Sahada en sık görülen durum nettir: otomasyon vardır ama süreç manuel ilerler.

Bu bir arıza değil, bir sinyaldir. Süreç net değildir, bağlam eksiktir ya da güven oluşmamıştır.

Bu nedenle SOAR projelerinde asıl soru otomasyon çalışıyor mu? değil, otomasyon gerçekten kullanılıyor mu? sorusudur.

Natica olarak yaklaşımımız, SOAR’ı yalnızca playbook yazımı olarak değil, operasyonun bir parçası olarak ele almaktır. Çünkü sahada farkı yaratan şey otomasyonun varlığı değil, o otomasyonun gerçekten kullanılıyor olmasıdır. Odak noktamız teknolojinin yanı sıra; süreç, veri kalitesi ve güvenin hep birlikte inşa edilmesidir.