Loglardan Tehdit İstihbaratına: Bir SIEM Sisteminin Anatomisi

Bir güvenlik operasyon merkezini (SOC — Security Operations Center) düşündüğümüzde akla gelen ilk şeylerden biri alarm ekranlarıdır. Ancak bir SOC'nin arka planda sağlıklı şekilde çalışabilmesi için bu alarmların beslendiği çok daha temel bir yapı vardır: Loglar

Bir sistemde gerçekleşen oturum açma, dosya oluşturma, ağ bağlantısı, servis çalıştırma veya başarısız kimlik doğrulama gibi olayların her biri gerisinde iz bırakır. Bu izler tek tek sistemlerde tutulduğunda ise güvenlik ekiplerinin bütün ortamı anlamlandırması oldukça zorlaşır. İşte SIEM (Security Information and Event Management) çözümleri tam olarak bu noktada devreye girer.

Staj sürecimde SIEM teknolojilerini incelerken, bir ürünün arayüzünü kullanmaya başlamadan önce arka planda logların nasıl toplandığını, normalize edildiğini, işlendiğini, korelasyona sokulduğunu ve sonunda bir güvenlik alarmına dönüştüğünü anlamanın ne kadar önemli olduğunu gördüm. Bu yazımda, SIEM ile yeni tanışanlar için SIEM hakkında öğrendiğim temel bilgileri ve bu sistemlerin arka planda nasıl çalıştığını paylaşacağım.

Log Nedir ve Neden Merkezi Olarak Yönetilmelidir?

En basit tanımıyla log, sistemlerin, uygulamaların ve ağ cihazlarının gerçekleştirdiği olayların zaman damgalı kaydıdır.

Örneğin bir kullanıcının sisteme başarılı şekilde giriş yapması, yanlış parola girmesi, bir sunucuda yeni bir process çalıştırılması veya bir firewall'ın belirli bir bağlantıyı engellemesi loglara yansıyabilir.

Tek bir bilgisayarda bu kayıtları incelemek mümkün olsa da kurum içerisindeki yüzlerce veya binlerce sistem düşünüldüğünde durum oldukça farklıdır. Her cihazın logunu ayrı ayrı incelemek hem zaman kaybına neden olur hem de saldırganın farklı sistemlerde bıraktığı izlerin bir bütün olarak görülmesini zorlaştırır.

Bu nedenle logların merkezi olarak toplanması ve analiz edilmesi, güvenlik görünürlüğünün temel gereksinimlerinden biridir. Bu noktada karşımıza SIEM kavramı çıkar.

SIEM Nedir?

SIEM, Security Information and Event Management ifadesinin kısaltmasıdır. Geleneksel olarak iki temel yaklaşımın birleşimi olarak açıklanabilir:

• SIM (Security Information Management): Logların uzun süreli saklanması, yönetilmesi ve raporlanması.
• SEM (Security Event Management): Güvenlik olaylarının gerçek zamanlı izlenmesi, korelasyonu ve alarm üretimi.

SIEM sistemleri bu iki yaklaşımı bir araya getirerek farklı kaynaklardan gelen güvenlik verilerini merkezi bir noktada toplar ve bu veriler üzerinden anlamlı güvenlik olayları oluşturmaya çalışır.

Günümüzde yaygın olarak karşılaşılan SIEM çözümleri arasında Splunk, IBM QRadar, Microsoft Sentinel, Elastic SIEM ve Logsign gibi platformlar bulunmaktadır.

Ancak farklı ürünlerin bulunması önemli bir probleme yol açar: Her sistem loglarını aynı formatta üretmez.

Farklı Loglar Nasıl Ortak Bir Dile Dönüştürülür?

Bir firewall'ın ürettiği log ile Windows Event Log'un yapısı veya bir Linux sunucusunun Syslog mesajı birbirinden oldukça farklı olabilir.

SIEM'in bu verileri birlikte analiz edebilmesi için log normalizasyonu gerekir. Bu süreçte farklı kaynaklardan gelen veriler belirli ortak şemalara veya formatlara eşlenebilir.

Örneğin:

• CEF (Common Event Format): Özellikle ArcSight ekosisteminde kullanılan, standart başlık ve key=value alanlarıyla genişletilebilen bir log formatıdır.
• LEEF (Log Event Extended Format): IBM QRadar tarafından kullanılan ve olayların hızlı şekilde ayrıştırılmasına uygun bir yapıdır.
• CIM (Common Information Model): Splunk'ta farklı kaynaklardan gelen alanların ortak veri modellerine eşlenmesini sağlar. Örneğin Authentication veya Network Traffic gibi modeller oluşturulabilir.
• ECS (Elastic Common Schema): Elastic ekosisteminde log alanlarının ortak bir yapıya dönüştürülmesini sağlayan açık bir şemadır.

Buradaki temel amaç, farklı sistemlerin farklı formatlarda ürettiği logları SIEM'in anlayabileceği ortak bir dile dönüştürmektir. Böylece farklı kaynaklardan gelen veriler, birlikte analiz edilebilir ve anlamlı güvenlik olaylarına dönüştürülebilir.

Loglar SIEM'e Nasıl Ulaşır?

Logların merkezi sisteme aktarılması için farklı veri toplama yöntemleri kullanılabilir. Bunlardan en bilinenlerinden biri Syslog protokolüdür. Syslog iletişiminde yaygın olarak UDP veya TCP üzerinden 514 numaralı port kullanılır. Syslog mesajlarında iki önemli kavram bulunur:

Facility, logu üreten kaynağın veya servisin türünü ifade eder. Örneğin auth, daemon veya local0-7 gibi değerler kullanılabilir.

Severity ise olayın önem derecesini belirtir ve 0 ile 7 arasında değer alır. 0 Emergency seviyesini, 7 ise Debug seviyesini ifade eder.

Log toplamada bir diğer önemli ayrım ise Agent-based ve Agentless yöntemleridir.

Agent-Based Veri Toplama

Bu yöntemde log kaynağı olan endpoint üzerine bir yazılım kurulur.

Örneğin:

• Splunk Universal Forwarder (Splunk sunucularına log ve makine verilerini iletmek için kullanılan hafif bir veri toplama agent'ı)
• WinCollect (Windows sistemlerinden event loglarını toplayarak IBM QRadar'a iletmek için kullanılan agent)
• Elastic Agent (endpoint, sunucu ve diğer veri kaynaklarından log ve güvenlik verilerini toplayıp Elastic Stack'e ileten agent)

gibi agent'lar kullanılabilir. Agent tabanlı yaklaşımın önemli avantajlarından biri, verilerin güvenli şekilde iletilmesinin yanında bağlantı kesintilerinde yerel kuyruklama gibi mekanizmalarla veri kaybının azaltılabilmesidir.

Agentless Veri Toplama

Bu yöntemde ise kaynak sisteme ayrıca bir agent kurulmadan veri toplanır.

WMI/WinRM, SNMP, Syslog veya REST API gibi mekanizmalar kullanılabilir. Özellikle geniş ve heterojen ağlarda hangi sistemin hangi yöntemle log göndereceği, SIEM mimarisinin önemli tasarım kararlarından biridir.

Bunun yanında sanallaştırma ve ağ katmanlarından gelen veriler de güvenlik görünürlüğünün önemli bir parçasıdır. Örneğin VMware NSX Distributed Firewall (DFW) logları, mikro segmentasyon ortamlarında sistemler arasındaki trafiğin izlenmesine ve olası lateral movement (yanal hareket) aktivitelerinin analiz edilmesine yardımcı olabilir.

Windows Event Log ve Sysmon ile Uç Nokta Görünürlüğü

SIEM'e gönderilen verilerin önemli bir kısmı endpoint sistemlerden gelir. Windows ortamında bunun temel kaynaklarından biri Windows Event Log mekanizmasıdır. Belirli Event ID'leri güvenlik analistleri için özellikle önemlidir.

Örneğin:

• 4624: Başarılı oturum açma
• 4625: Başarısız oturum açma
• 4672: Özel ayrıcalıkların atanması
• 4688: Yeni process oluşturulması
• 4720: Yeni kullanıcı oluşturulması
• 4728: Güvenlik grubuna kullanıcı eklenmesi
• 1102: Security loglarının temizlenmesi
• 104: System loglarının temizlenmesi

Örneğin arka arkaya çok sayıda 4625 olayının görülmesi bir brute-force saldırısına işaret edebilir. Ardından aynı hesap için 4624 başarılı oturum açma olayının görülmesi ise olayın daha detaylı incelenmesini gerektirebilir. Aynı Event ID'nin farklı Logon Type değerleri de olayın bağlamını değiştirebilir.

Örneğin:

• Logon Type 2: Yerel/console oturumu
• Logon Type 3: Ağ üzerinden gerçekleştirilen oturum
• Logon Type 10: Remote Desktop Protocol (RDP) oturumu

Bu nedenle yalnızca "başarılı giriş gerçekleşti" bilgisini görmek yerine, kim giriş yaptı, nereden giriş yaptı ve hangi yöntem kullanıldı? sorularını birlikte değerlendirmek gerekir.

Sysmon ile Daha Derin Görünürlük

Windows'un standart event logları önemli bilgiler sağlasa da daha ayrıntılı endpoint görünürlüğü gerektiğinde Sysmon (System Monitor) kullanılabilir.

Özellikle aşağıdaki Sysmon Event ID'leri güvenlik analizlerinde önemlidir:

• Event ID 1 — Process Creation: Hangi process'in, hangi parent process tarafından çalıştırıldığını ve komut satırı bilgilerini incelemeye yardımcı olur.
• Event ID 3 — Network Connection: Bir process'in hangi IP adresine ve porta bağlantı kurduğunun görülmesini sağlar.
• Event ID 7 — Image Loaded: DLL ve benzeri modüllerin yüklenmesi hakkında görünürlük sağlar.
• Event ID 11 — File Create: Dosya oluşturma aktivitelerinin takip edilmesine yardımcı olur.

Örneğin bir kullanıcının çalıştırdığı powershell.exe process'inin ardından şüpheli bir dış IP adresine bağlantı kurulduğunu düşünelim. Tek başına process logu veya network logu çok anlamlı olmayabilir. Ancak bu iki veri birlikte değerlendirildiğinde olayın güvenlik açısından önemi çok daha net hale gelir.

Bu bizi SIEM'in en önemli özelliklerinden birine götürür: log korelasyonu

SIEM Mimarisi: Log Nereden Gelir, Nerede İşlenir?

Bir SIEM sistemini anlamanın en kolay yollarından biri, verinin sistem içerisinde nasıl hareket ettiğini takip etmektir. Genel bir mimariyi aşağıdaki gibi düşünebiliriz:

En alt katmanda Log Sources bulunur. Bunlar; Firewall'lar, Windows Event Log , Syslog kaynakları, DNS, Proxy, Uygulamalar, Sunucular gibi sistemler olabilir.

Bu kaynaklardan gelen veriler Event Collector tarafından toplanır. Collector, verileri ayrıştırabilir, filtreleyebilir ve işlenmek üzere ilgili bileşenlere aktarabilir.

Ardından Event Processor, olayları belirlenen kurallarla karşılaştırır ve korelasyon gerçekleştirir. Burada güvenlik açısından anlamlı görülen olaylar alarm haline getirilebilir.

İşlenen veriler ise Data katmanında indekslenir ve saklanır.

En üstte ise Console bulunur. SOC analistleri bu arayüz üzerinden alarmları inceleyebilir, dashboard'ları takip edebilir, sorgular çalıştırabilir ve güvenlik kurallarını yönetebilir. Bu yapının yalnızca güvenlik açısından değil, performans açısından da tasarlanması gerekir.

EPS ve Aggregation Neden Önemlidir?

SIEM mimarisinde sık karşılaşılan kavramlardan biri EPS (Events Per Second) değeridir. EPS, sistemin saniyede işlediği olay sayısını ifade eder.

Örneğin saniyede binlerce log üreten bir ortam ile saniyede milyonlarca log üreten bir ortamın aynı donanım ve mimariyle yönetilmesi beklenemez.

EPS değeri; kapasite planlamasını, işlemci ve depolama gereksinimlerini ve bazı SIEM ürünlerinde lisans maliyetlerini doğrudan etkileyebilir.

Bir diğer yöntem ise aggregation işlemidir. Aggregation, Aynı türde tekrarlayan olayların uygun şekilde gruplanması, gereksiz veri tekrarını ve sistem üzerindeki yükü azaltmaya yardımcı olur.

Log Korelasyonu: Tek Bir Log Bazen Yeterli Değildir

SIEM'in asıl gücü yalnızca logları toplamasından değil, farklı loglar arasındaki ilişkileri kurabilmesinden gelir. Bir saldırıyı düşünelim:

Önce bir kullanıcı hesabı için çok sayıda başarısız giriş gerçekleşiyor. Ardından başarılı bir giriş geliyor. Daha sonra aynı kullanıcının yetkili bir gruba eklendiği görülüyor ve son olarak şüpheli bir process çalıştırılıyor.

Bu olayların her biri tek başına incelendiğinde farklı bir güvenlik problemi gibi görünebilir.

Ancak SIEM bu olayları;

4625 → 4624 → 4728 → 4688

gibi bir zaman çizelgesi içerisinde ilişkilendirebildiğinde, analistin önüne çok daha anlamlı bir senaryo çıkar. Bu işleme log correlation denir.

SIEM sistemleri bu amaçla farklı kaynaklardan gelen verileri birleştirebilir, önceden tanımlanmış kuralları çalıştırabilir ve koşullar sağlandığında otomatik alarm üretebilir. Korelasyon sırasında kullanılan temel alanlar arasında:

• src_ip / source_id
• dest_ip / dest_id
• src_port / dest_port
• user / account_name
• action / status
• process_name / parent_process_name
• bytes_in / bytes_out gibi alanlar bulunabilir.

Örneğin ağ trafiğini incelerken src_ip kaynağı, dest_ip hedefi, src_port ve dest_port ise iletişimin gerçekleştiği portları ifade edebilir.

Güvenlik analizlerinde 22 (SSH), 53 (DNS), 80/443 (HTTP/HTTPS), 88 (Kerberos), 389/636 (LDAP/LDAPS), 445 (SMB) ve 3389 (RDP) gibi portlar da bağlama göre önem kazanabilir.

Ancak SIEM analizinde yalnızca IP ve port bilgilerine bakmak yeterli değildir. Kullanıcı, process, zaman, sistemin kritiklik seviyesi ve olayın gerçekleştiği bağlam birlikte değerlendirilmelidir.

UEBA: Normal Davranıştan Sapmaları Yakalamak

Kurallara dayalı sistemlerin önemli bir sınırı vardır: Önceden tanımlanmamış bir davranışı yakalamak zor olabilir. İşte bu noktada UEBA (User and Entity Behavior Analytics) yaklaşımı devreye girer.

UEBA, kullanıcıların, servis hesaplarının ve cihazların normal davranışlarını analiz ederek bir baseline oluşturmaya çalışır.

Örneğin normalde yalnızca mesai saatlerinde çalışan bir hesabın gece saatlerinde sisteme giriş yapması, daha önce erişmediği hassas bir dizine erişmesi veya normalden çok daha yüksek miktarda veri aktarması bir anomali olarak değerlendirilebilir.

Buradaki amaç, yalnızca "bu olay daha önce tanımlandı mı?" sorusunu sormak değil; "bu davranış bu kullanıcı veya cihaz için normal mi?" sorusunu da cevaplayabilmektir.

Log Retention: Güvenlik Kadar Uyumluluk da Önemli

Logların SIEM üzerinde toplanmasının amacı yalnızca saldırıları tespit etmek değildir. Kurumsal ortamlarda logların belirli süreler boyunca saklanması; olay sonrası inceleme, adli analiz ve yasal/kurumsal uyumluluk açısından da önem taşır.

Türkiye'de 5651 sayılı Kanun, kişisel verilerin korunması kapsamında KVKK, uluslararası tarafta ise GDPR, ISO/IEC 27001 ve PCI-DSS gibi düzenleme ve standartlar log yönetimi ve izlenebilirlik açısından çeşitli gereksinimler ortaya koyabilir. Bu nedenle SIEM mimarisinde retention policy önemli bir tasarım konusudur.

Sık kullanılan loglar hızlı erişim sağlamak amacıyla daha performanslı hot storage alanlarında tutulabilirken, daha eski kayıtlar cold storage veya arşivleme sistemlerine taşınabilir.

Burada yalnızca "ne kadar süre saklayacağız?" sorusu değil, aynı zamanda logların bütünlüğünü nasıl koruyacağız ve gerektiğinde bu kayıtlara nasıl erişeceğiz? soruları da önemlidir.

SIEM'den SOAR'a: Tespitten Müdahaleye

SIEM, SOC ortamında tehditlerin görünür hale getirilmesi ve alarm üretilmesi açısından kritik bir role sahiptir. Ancak bir saldırı tespit edildiğinde yalnızca alarm üretmek her zaman yeterli değildir.

Örneğin bir kullanıcının hesabının ele geçirildiğinden şüphelenildiğini düşünelim. Analistin alarmı incelemesi, hesabı doğrulaması, ilgili IP adresini kontrol etmesi ve gerekirse hesabı veya bağlantıyı engellemesi gerekebilir. Bu işlemlerin tamamının manuel yapılması, özellikle yüksek alarm hacmine sahip SOC ortamlarında ciddi zaman kaybına neden olabilir.

Burada SOAR (Security Orchestration, Automation and Response) devreye girer. SIEM tarafından üretilen yüksek öncelikli bir alarm, SOAR üzerinde tanımlanan bir playbook tarafından tetiklenebilir. Senaryoya bağlı olarak şüpheli bir hesabın devre dışı bırakılması, zararlı bir IP adresinin firewall üzerinde engellenmesi veya ilgili olayın ticket sistemine aktarılması gibi işlemler otomatikleştirilebilir.

Böylece SIEM'in temel olarak yaptığı "tehdidi gör ve alarm üret" yaklaşımı, SOAR ile birlikte "tehdidi gör, değerlendir ve uygun müdahaleyi otomatikleştir" yaklaşımına dönüşür.

Final

SIEM'i yalnızca logların toplandığı bir platform olarak düşünmek, aslında sistemin en önemli kısmını gözden kaçırmak anlamına gelebilir. Log kaynağından başlayan süreç; toplama, normalizasyon, indeksleme, korelasyon, analiz, alarm üretimi ve gerektiğinde otomatik müdahale aşamalarından oluşan büyük bir veri akışına dönüşüyor.

Bu yapıyı incelerken benim için en önemli noktalardan biri de tek bir log kaydının çoğu zaman yeterli olmamasıydı. Asıl değer, farklı kaynaklardan gelen olayların zaman, kullanıcı, sistem ve ağ bağlamlarıyla bir araya getirilmesiyle ortaya çıkıyor.

Bir sonraki yazımda ise SIEM çözümlerinden biri olan Splunk'ı ele alacağım