Bir Ürün SOC'a Ne Göndermeli?

Kurumsal satın alma şartnamelerinin neredeyse tamamında aynı madde vardır: ürün, kendi logunu ve eylem logunu kurumun syslog kaynağına göndermelidir. Bu madde çoğu zaman tek satırdır ve tek satır olduğu için hafife alınır. Oysa arkasında, doğru cevaplanması gereken altı ayrı soru durur. Bu yazı o soruları ve makul cevaplarını anlatıyor.

Şartnamedeki Madde Neden Var

Sebep tek cümleyle şudur: bir sistemin kaydı, o sistemi yönetenin değiştiremeyeceği bir yerde de durmalıdır.

Bir ürün kendi denetim izini kendi veritabanında tutar. Bu kayıt doğru olabilir, imzalı olabilir, hash zinciriyle korunuyor olabilir. Ama o veritabanına tam yetkiyle erişen biri için hepsi aynı çatı altındadır. Denetimin varlık sebebi tam olarak budur: kurumun kendi kayıtlarına kendi verdiği not tek başına yeterli sayılmaz.

SOC ise tanımı gereği farklı bir ekibin elindedir, çoğu kurumda ayrı bir yetki alanıdır ve saklama süresi ile değiştirilemezliği kendi platformu garanti eder. Olay oraya düştüğü anda, kaydın korunması artık ürünün sorumluluğu olmaktan çıkar.

Burada bir ayrımı atlamamak gerekiyor: log toplamak ile kanıt üretmek aynı şey değildir. SOC'a akıtma, kaydın dışarıda da bulunmasını sağlar; kaydın kendi içinde bozulmadığını göstermek ayrı bir iştir ve log yönetimi tek başına bunu üretmez. Çapa akışının bu yazıda ayrıca ele alınmasının sebebi de budur; çapanın dışarı teslim edilmesi ayrı bir yazının konusu.

İkinci bir sebep daha var ve genelde konuşulmaz: korelasyon. SOC, veritabanı tarafındaki bir olayı ağ, kimlik ve uç nokta tarafındaki olaylarla aynı zaman çizelgesine koyabilir. Tek başına masum görünen bir çalıştırma, aynı dakikada yapılan olağandışı bir girişle birlikte anlam kazanır.

Karıştırılmaması Gereken Üç Akış

Şartnamedeki "kendi logu ve eylem logu" ifadesi bilinçli bir ayrımdır. Üçüncüsünü de eklemek gerekir ve üçü teknik olarak birbirine benzemez.

Akış	İçerik	Kaybı ne demek
Ürünün kendi logu	Açılış, hata, servis durumu, yetki reddi, başarısız giriş	Tolere edilir, işletim bilgisidir
Eylem logu	Talep açıldı, onaylandı, reddedildi, çalıştırıldı, maskeleme kararı, kanıt indirildi	Tolere edilmez, kanıttır
Çapa	Zincirin o ana kadarki özeti ve imzası	Tolere edilmez

Aradaki kritik fark şu: eylem logu ve çapa zaten bir tabloda duruyor. Ürünün kendi logu durmuyor. Bu tek fark, iki farklı teslim mekanizmasını zorunlu kılar ve aşağıdaki "kesinti" bölümünün tamamı buradan çıkar.

Dördüncü ve küçük bir akış daha eklenmelidir: nabız. Sabit aralıkla gönderilen bir yaşam işareti. SOC'un en zayıf noktası sessizliktir; bir kaynak olay göndermeyi bıraktığında SOC bunu sakin bir gün sanır. Nabız, "bu kaynak hâlâ ayakta" demenin standart yoludur ve SOC ekipleri bunu bekler.

Hangi Biçim

Dört seçenek konuşulur ve aralarındaki fark sanıldığı kadar büyük değildir.

• RFC 5424 syslog, gövdesi JSON. Modern toplayıcıların en rahat yuttuğu biçim. Alıcı tarafta kendi şemasına serbestçe oturur.
• CEF. ArcSight kaynaklı, geniş kabul görmüş. Alan eşlemesi gerektirir.
• LEEF. QRadar için. Türkiye'de QRadar yaygın olduğu için atlanmamalı.
• Düz JSON. Dosyaya yazan ve kendi aracıyla okuyan kurumlar için.

Pratikte SOC ekiplerinin verdiği cevap genelde aynıdır: syslog ve JSON ile herkes iyi anlaşır, ikisi de yaygın olarak bilinir; diğer biçimler de ayrıştırılır ama bu ikisi en pratiğidir. Yani biçim tartışması çoğu zaman gereğinden fazla büyütülür. Asıl ayrıştırıcı sorular taşıma ve kesinti davranışıdır.

Hacim tarafındaki farkı da burada netleştirmek gerekiyor: yönetişim olayı göndermek ile veritabanı etkinliğini izlemek ayrı işlerdir ve ikisinin SOC üzerindeki yükü kıyaslanamaz. Aradaki ayrımı ayrı bir yazıda ele aldık.

Taşıma tarafında tek bir kural vardır: UDP varsayılan olmamalıdır. UDP tek pakete sığmayan mesajı kaybeder ve kaybettiğini söylemez. Varsayılan, TCP üzerinde TLS olmalıdır. TLS kullanılıyorsa sunucu sertifikasının doğrulanamadığı durumda bağlantının reddedilmesi, sessizce düz metne düşülmemesi gerekir.

Toplayıcı Kapalıyken Ne Oluyor

Bu, bir ürünü gerçekten ayıran sorudur ve şartnamede nadiren yazar. Toplayıcı bakıma girer, ağ kesilir, sertifika süresi dolar. Üç gün boyunca olaylar ne oldu?

Sektörde iki yaklaşım var.

Disk kuyruğu. Klasik log ileticilerinin (rsyslog, syslog-ng) yaptığı iş. Olaylar diske yazılır, bağlantı gelince gönderilir. Bu yöntem, ellerindeki verinin başka kopyası olmayan bileşenler için doğrudur.

Kaynaktan yeniden okuma. Eylem logu ve çapa için daha doğru olan budur, çünkü olay zaten denetim tablosunda duruyor. Ürün, nereye kadar gönderdiğini tek bir sayı olarak tutar; bağlantı geldiğinde o numaradan itibaren sırayla okur. Üç gün kapalı kalsa üç günü sırasıyla gönderir ve hiçbir olay kaybolmaz.

İkinci yöntemin bir yan faydası daha var. Denetim izi tablosu yalnız ekleme yapılan bir tablodur ve her satırı bir öncekine bağlıdır. "SIEM'e gönderildi" diye bir kolon eklemek o tabloyu güncellenebilir hale getirir ve tablonun en güçlü iddiasını zayıflatır. Tek bir ilerleme sayısı tutmak bunu gerektirmez.

Bir de mükerrerlik konusu var ve dürüst cevabı şudur: syslog üzerinde tam olarak bir kez teslim mümkün değildir. Gönderim yapılıp ilerleme kaydedilmeden süreç çökerse aynı olay bir kez daha gider. Doğru çözüm mükerrerliği engellemeye çalışmak değil, her olaya kararlı ve benzersiz bir kimlik vermektir; SOC o kimlik üzerinden tekilleştirir. "En az bir kez teslim, kararlı olay kimliğiyle" cümlesi bu konuda beklenebilecek en dürüst taahhüttür.

Son olarak: SIEM'e gönderim hiçbir koşulda ana iş akışını bloklamamalıdır. Toplayıcı yavaşladığında bir talebin onaylanması gecikiyorsa, kanıt katmanı üretimi durduran bir bileşene dönüşmüş demektir. Gönderim ayrı bir yolda çalışmalı ve hata yutulmalıdır; ama sessizce değil, ardışık hata sayısı bir eşiği geçtiğinde bildirim üretecek şekilde.

SOC'a Gitmemesi Gerekenler

Bu bölüm atlanırsa entegrasyonun kendisi bir veri sızıntısı yoluna dönüşür. SOC toplayıcısı çoğu kurumda ayrı bir ekibin elindedir ve bazen dış hizmet sağlayıcıdadır.

• Sorgu sonuç verisi. Hiçbir koşulda. Sorgunun çalıştığı, kaç satır döndüğü ve hangi kolonların maskelendiği gider; verinin kendisi gitmez.
• Parolalar, bağlantı dizeleri, anahtarlar ve jetonlar. Denetim izinde zaten maskelenmiş olmalıdır; SIEM yolunda maskeleme ikinci kez uygulanmalıdır. Tek noktaya güvenmek bu konuda yeterli değildir.
• Çalıştırılan betiğin tam metni. Varsayılan olarak gitmemelidir, çünkü betik iş verisi içerebilir. Yerine betiğin özeti, nesne adları ve ifade sayısı gider. Kurum isterse tam metni açabilmelidir, ama bu ayrı bir tercih olmalı ve varsayılanı kapalı olmalıdır.
• Kanıt dosyasının içeriği. Dosyanın üretildiği ve kimin indirdiği gider, içeriği gitmez.

Filtrenin Alt Sınırı

Kurumun kapsamı daraltabilmesi meşrudur; hacim yönetilmek istenir. Ama burada gerçek bir tehlike vardır ve şartnamelerde neredeyse hiç yazmaz: bir kurum kendi aleyhine olan olayları SOC'tan gizleyebilir. Acil müdahaleleri, atlanan onay adımlarını ve kapatılan kontrolleri filtrelemek, entegrasyonun amacını tersine çevirir.

Doğru tasarımda bazı olaylar filtrelenemez. Acil müdahale, kontrol zayıflatma, yetki reddi ve çapa, eşik ne olursa olsun gider.

Bundan daha inceliklisi de var. Filtreyi değiştirme hareketinin kendisi bir kontrol zayıflatma olayıdır ve SOC'a gitmelidir. Ama burada bir tuzak vardır: değişiklik yürürlüğe girdikten sonra gönderilirse, "eylem logunu kapat" kararı zaten kapalı akışta kalır ve SOC'a hiç ulaşmaz. Bu yüzden filtre değişikliği, değişiklik uygulanmadan önceki yapılandırmayla duyurulmalıdır. Ancak o zaman "kurum kapsamı daraltabilir ama daralttığını gizleyemez" cümlesi gerçekten çalışır.

Ürün Değerlendirirken Sorulacak Yedi Soru

Şartnamedeki tek satır, "gönderiyor musunuz" sorusuna indirgenirse herkes evet der. Ayrımı aşağıdaki sorular yapar.

1. Ürünün kendi logu ile eylem logu ayrı akışlar mı, yoksa hepsi tek kanaldan mı akıyor?
2. Toplayıcı üç gün kapalı kalsa ne olur? Kayıp olur mu, olursa hangi akışta?
3. Aynı olay iki kez giderse SOC bunu neyle ayırt eder?
4. Toplayıcı erişilemezken ürünün kendi iş akışı yavaşlar mı?
5. Bağlantı koptuğunda kim haberdar oluyor ve nasıl?
6. Kapsamı daraltan bir ayar değişikliği SOC'a bildiriliyor mu, hangi yapılandırmayla?
7. Gönderilen mesajın içinde hassas veri bulunma ihtimali var mı, hangi alanlar maskeleniyor?

İlk beş soru, entegrasyonun kanıt taşıyıp taşımadığını gösterir. Son iki soru, entegrasyonun yeni bir risk üretip üretmediğini gösterir. Bir ürün her iki tarafa da net cevap veremiyorsa, şartnamedeki maddeyi teknik olarak karşılıyor ama amacını karşılamıyordur.