SIEM’de bir log kaynağını görmek, o sistemde güvenlik açısından ihtiyaç duyulan bütün aktivitelerin gerçekten kaydedildiğini kanıtlıyor mu? Bir olay yaşandığında mevcut kayıtlarla kim, ne zaman, nereden ve ne yaptı sorularını cevaplayabiliyor muyuz?
Daha kritik soru ise şu: Collector çalışıyor görünüyorsa, ihtiyacımız olan telemetry’nin gerçekten üretildiğinden emin olabilir miyiz?
Güvenlik görünürlüğü yalnızca log toplamakla başlamıyor. Önce hangi davranışların görünür olması gerektiğini tanımlamak, ardından bu davranışların kullanılabilir telemetry olarak gerçekten temsil edildiğini doğrulamak gerekiyor.
Log Tutmak ile Olayı Yeniden Kurabilmek Aynı Şey mi?
Türkiye’deki bazı veri ihlali kararları bu ayrımı oldukça net gösteriyor.
Kişisel Verileri Koruma Kurulunun 16 Mayıs 2024 tarihli 2024/790 sayılı kararında, ilgili uygulamada Amazon Web Services sisteminin varsayılan loglarının bulunduğu, ancak yazılım geliştirme aşamasında yeni log kayıtları henüz eklenmediği için yapılan işlemlerin tamamının kayıt altına alınamadığı belirtiliyor. Kurul ayrıca tüm veri tabanı alanlarında yeterli log yapısı bulunmadığından yetkisiz erişimin nasıl gerçekleştirildiğinin kesin olarak tespit edilemediğini aktarıyor.
Buradaki problem “hiç log yoktu” şeklinde özetlenemez.
Log vardı; fakat olayın yeniden oluşturulması için gereken kapsama sahip değildi.
Benzer şekilde, Kişisel Verileri Koruma Kurulunun 7 Kasım 2024 tarihli 2024/1898 sayılı kararında, kısıtlı sunucu loglarında yüksek miktarda uzaktan bağlantı denemeleri tespit edildiği, ancak sunucu üzerindeki log kayıtlarının silinmiş olması nedeniyle ilk erişimin nasıl sağlandığına kesin olarak ulaşılamadığı belirtiliyor. Kararda ayrıca sunucu loglarının merkezi olarak tutulması öneriler arasında yer alıyor.
26 Aralık 2024 tarihli 2024/2196 sayılı kararda ise ihlale ilişkin önemli bilgiler içerebilecek log kayıtlarına ulaşılamadığı ve kayıtların şifrelenmiş olduğunun belirtildiği görülüyor. Kurul, bu durumun yanı sıra diğer bulguları da değerlendirerek veri güvenliğinin takibi konusunda eksiklikler bulunduğu sonucuna varmıştı.
Bu vakalar Türkiye’deki bütün kurumlara genellenemez. Ancak önemli bir teknik gerçeği somutlaştırırlar:
Log bulunması ile olay araştırmasına yetecek telemetry bulunması aynı şey değildir.
SIEM’den Önce Görünürlük Nerede Başlıyor?
Bir SIEM yalnızca kendisine ulaşan ve kullanılabilir durumda olan veriyi analiz edebilir. Kaynak sistem belirli bir aktiviteyi hiç kaydetmiyorsa sonraki katmanların bu eksikliği geriye dönük olarak oluşturması mümkün değildir.
Bu nedenle ilk kontrol noktası SIEM değil, kaynak tarafı denetimidir (source-side auditing).
Bir Windows sunucusunun SIEM’e bağlı olması yalnızca veri akışı için bir bağlantı bulunduğunu gösterir. İlgili audit policy’nin hangi olayları ürettiği, hangi kanalların toplandığı ve olay araştırması sırasında gerekli olacak alanların gerçekten kayıt altına alınıp alınmadığı ayrıca değerlendirilmelidir.
Aynı yaklaşım uygulamalar, veri tabanları, firewall’lar ve diğer altyapı bileşenleri için de geçerlidir.
Buradaki temel kavram kapsama (coverage): Görmemiz gereken güvenlik aktivitesi gerçekten telemetry tarafından temsil ediliyor mu?
Beklenen Telemetry Sözleşmesi
Bu soruyu daha sistematik hâle getirmek için bu yazıda Beklenen Telemetry Sözleşmesi — Expected Telemetry Contract olarak adlandıracağımız bir analiz modeli kullanılabilir.
Bu kavram bir endüstri standardı değildir. Güvenlik görünürlüğünü kaynaktan hedefe kadar değerlendirmek için kullanılabilecek bir kontrol çerçevesidir.
Zincir şu şekilde düşünülebilir:
Beklenen aktivite → beklenen event → gerekli alanlar → collection noktası → processing/routing → hedef sistem → doğrulama
Önce güvenlik açısından görünür olması gereken davranış tanımlanır. Ardından bu davranışın hangi event veya log kaydıyla temsil edilmesi gerektiği belirlenir.
Sonraki soru yalnızca event’in oluşup oluşmadığı değildir. Olay araştırması için kullanıcı, zaman, kaynak sistem, hedef nesne, sonuç ve benzeri gerekli alanların korunup korunmadığı da değerlendirilmelidir.
Böylece “Bu sistemden log alıyor muyuz?” sorusu daha anlamlı bir soruya dönüşür:
“Güvenlik açısından ihtiyaç duyduğumuz davranış gerçekten kullanılabilir telemetry olarak mevcut mu?”
Üç Farklı Use Case Üzerinden Coverage Problemi
Windows ve Kimlik Olayları
Bir kurum yeni veya ayrıcalıklı kullanıcı hesabı oluşturulmasını görünür hâle getirmek istiyor olsun.
“Windows Security loglarını topluyoruz” demek tek başına yeterli değildir. İlgili davranış için hangi audit politikasının etkin olması gerektiği, hangi event’in oluşacağı ve olay araştırmasında hangi alanların kullanılacağı önceden tanımlanmalıdır.
NXLog Community Edition, Windows Event Log verilerini
im_msvistalogmodülü üzerinden okuyabilir ve kaynak tarafından üretilen event alanlarını işleyebilir. Ancak bu yetenek, Windows’un baştan üretmediği bir audit event’ini oluşturmaz. NXLog dokümantasyonundaim_msvistalogmodülünün Windows Event Log altyapısından event topladığı açıkça belirtiliyor.Yani coverage problemi collector’dan önce başlayabilir.
Uygulama ve Veri Tabanı Olayları
İkinci senaryoda bir uygulama kullanıcı login ve logout hareketlerini kaydediyor, ancak hassas veri görüntüleme işlemlerini loglamıyor olsun.
Collector ilgili dosyayı veya event akışını eksiksiz okuyabilir. SIEM de gelen kayıtları başarıyla indeksleyebilir.
Buna rağmen olay sonrasında şu soruya cevap verilemeyebilir:
Hangi kullanıcı hangi hassas kaydı görüntüledi?
Buradaki eksiklik collection veya SIEM problemi değildir. Telemetry daha kaynak uygulamada üretilmemiştir.
Bu ayrım özellikle özel geliştirilmiş uygulamalarda önemlidir. Bir uygulama “log üretiyor” olabilir; fakat güvenlik use case’inin gerektirdiği aktiviteleri kaydetmiyor olabilir.
Network ve Syslog Akışı
Üçüncü örnekte bir firewall Syslog mesajları gönderiyor olsun.
İlk bakışta kaynak çalışıyor ve log akışı devam ediyor olabilir. Ancak hangi event sınıflarının gönderildiği, severity filtrelerinin neyi dışarıda bıraktığı, gerekli alanların korunup korunmadığı ve kayıtların hangi hedeflere yönlendirildiği ayrıca kontrol edilmelidir.
Teknik olarak yanlış bir filtre veya dar kapsamlı bir kaynak yapılandırması, collector tamamen sağlıklı olsa bile görünürlük boşluğu oluşturabilir.
NXLog Community Edition Bu Mimaride Nerede Konumlanıyor?
NXLog Community Edition bu mimaride SIEM öncesinde telemetry toplamak, işlemek ve yönlendirmek için kullanılabilecek bir collector/processor olarak düşünülebilir.
NXLog CE dokümantasyonu; Windows Event Log gibi farklı kaynaklardan veri toplanmasını ve route yapısıyla input, processing ve output katmanlarının birbirine bağlanmasını desteklediğini gösteriyor.
im_msvistalogWindows Event Log verilerini toplarken, route yapısı event’lerin sonraki modüllere aktarılmasını sağlıyor.Ancak sınırların doğru çizilmesi gerekiyor.
NXLog CE, kaynağın hiç üretmediği audit event’ini oluşturamaz. Eksik source-side auditing problemini tek başına çözemez. Aynı şekilde üçüncü taraf bir SIEM’in kendisine gönderilen her kaydı kalıcı biçimde indekslediğini veya retention politikasını doğru uyguladığını garanti etmez.
Detection engineering, correlation ve SOC analitiği de ayrı katmanlardır.
Community Edition’ı büyük agent filoları için native merkezi governance platformu olarak konumlandırmak da doğru olmaz. Bu tür merkezi yönetim yetenekleri NXLog’un ticari platform dokümantasyonunda ayrı bir katman olarak ele alınıyor.
Bu nedenle NXLog CE’nin bu makaledeki rolü çözümün tamamı değil, telemetry pipeline içindeki collection, processing ve routing katmanıdır.
Logun Var Olduğunu Değil, İşe Yaradığını Kanıtlamak
SIEM öncesi görünürlüğü değerlendirirken beş soruluk bir model yararlı olabilir. Bu da bir endüstri standardı değil, konuyu katmanlara ayırmak için kullanılan analitik bir çerçevedir.
Coverage: Görmemiz gereken güvenlik aktivitesi gerçekten telemetry olarak mevcut mu?
Delivery: Üretilen event collector ve hedef sistem arasındaki yolu tamamlıyor mu?
Quality: Kayıt gerekli alanları, zaman bilgisini ve semantik anlamını koruyor mu?
Efficiency: İhtiyaç duyulan veri doğru hedefe ve doğru işleme politikasıyla mı gidiyor?
Verification: Bütün zincirin beklediğimiz biçimde çalıştığını kanıtlayabiliyor muyuz?
Bu beş katmanın ilki coverage’dır. Çünkü kaynağın hiç üretmediği bir güvenlik event’ini sonraki katmanlarda geri kazanamayız.
Bu nedenle bir SIEM projesinde ilk envanter yalnızca “hangi log kaynakları bağlı?” sorusuna cevap vermemelidir. Kritik güvenlik use case’leri için hangi aktivitelerin görünür olması gerektiği ve bunların hangi telemetry ile temsil edildiği de belgelenmelidir.
Sistem yöneticisi açısından soru şuna dönüşür:
Hangi kritik aktiviteleri hiç loglamıyor olabilirim?
SOC açısından:
Detection için beklediğim telemetry gerçekten üretiliyor mu?
Teknik karar verici açısından ise mesele SIEM lisansından önce veri katmanındaki kontrolün tanımlanmasına dönüşür.
Bir Sonraki Soru: Event Oluştuysa Gerçekten Ulaşıyor mu?
Coverage doğrulandıktan sonra problem bitmiyor.
Doğru event kaynak sistemde gerçekten oluşuyorsa bu kez collector’ın onu alıp almadığı ve hedef sisteme eksiksiz ulaştırıp ulaştırmadığı sorulmalıdır.
NXLog dokümantasyonundaki flow control davranışı bu ayrımın neden önemli olduğunu gösteriyor. NXLog’ta flow control varsayılan olarak etkin. Bir sonraki modül veriyi kabul edemez ve kuyruğu dolarsa, önceki input veya processor duraklatılabiliyor. Flow control devre dışı bırakılmışsa, sonraki modülün kuyruğu dolduğunda event’ler atılabiliyor.
Bu ise artık coverage değil, delivery problemidir.
UDP ile TCP arasındaki fark, buffering, queue doluluğu, back-pressure, destination outage ve “sent” ile “stored” arasındaki ayrım ayrı bir değerlendirme gerektirir.
Güvenlik görünürlüğü SIEM ekranında başlamaz. Hangi davranışın kaydedilmesi gerektiğini bilmek ve bu davranışın kullanılabilir telemetry olarak temsil edildiğini kanıtlamakla başlar.
“Log kaynağı bağlı” yalnızca bir konfigürasyon bilgisidir.
“İhtiyaç duyduğumuz telemetry gerçekten mevcut” ise doğrulanması gereken bir güvenlik iddiasıdır.
Peki doğru event gerçekten oluşuyorsa, hedef sisteme ulaştığını nasıl kanıtlarız?
SIEM: Log Tutuyoruz, Peki Olayı Yeniden Kurabiliyor muyuz?
Kaynak sistemlerden güvenlik analitiğine uzanan SIEM öncesi telemetry görünürlüğü.