Selamun Aleyküm
bu bölümde ise dostlarım SOC analistlerinin olayları genel olarak nasıl değerlendirdiklerini risk sınıflarını ve SOC analistlerinin kendi içinde oluşturduğu ekosisteme beraber göz atacağız inşallah sizler için faydalı bir konu olur
peki nedir bu uyarılar şöyle özetleyelim
SOC ekipleri, binlerce farklı sistemden günde milyonlarca log alabilir. Bu logların büyük kısmı olağan ve beklenen işlemleri gösterirken, bazıları potansiyel tehditleri işaret eder. İşte bu noktada alarm (alert) devreye girer: belirli bir olay veya olaylar zinciri gerçekleştiğinde güvenlik sisteminin ürettiği uyarı.
Alarm sayesinde SOC analistleri milyonlarca ham log arasında kaybolmaz; yalnızca şüpheli ve anormal görünen olaylara odaklanır. Böylece günlük iş yükü milyonlarca log yerine sadece birkaç düzine alarmı incelemekle sınırlı kalır.
Uyarı Yönetim Platformları
Genel olarak bu 8 madde üstüne SOC analistleri olayları değerlendirmektedir dostlarım A şirketindede çalışsanız B şirketindede temel mantık bunun üzerinedir
bu bölümde ise dostlarım SOC analistlerinin olayları genel olarak nasıl değerlendirdiklerini risk sınıflarını ve SOC analistlerinin kendi içinde oluşturduğu ekosisteme beraber göz atacağız inşallah sizler için faydalı bir konu olur
Olaylar ve Uyarılar
Şöyle bir hayal edelim dostlarım bir stajer olarak işe başladınız. Ve sizin üstünüz olan SOC L1 veyahut SOC L2 analistinin çalıştığı bilgisayar ekranına bakıyorsunuz yüzlerce uyarı mesajı görüyoruz bazı mesajlar Email Marked as Phishing bazıları Unusual Gmail Login Location ve en korkutucu ve sıkıntılı olanlar ise Unapproved Mimikatz Usagepeki nedir bu uyarılar şöyle özetleyelim
- Email Marked as Phishing → Kullanıcılar veya sistemler tarafından şüpheli e-postaların işaretlenmesiyle oluşur.
- Unusual Gmail Login Location → Normalden farklı bir coğrafi konumdan oturum açma girişimi tespit edildiğinde çıkar.
- Unapproved Mimikatz Usage → Yetkisiz kimlik bilgisi çıkarma aracının çalıştırılması gibi kritik bir güvenlik ihlali algılandığında görünür.
Etkinliklerden Uyarılma
Bir güvenlik süreci, her şeyden önce bir olayla başlar: örneğin bir kullanıcının sisteme giriş yapması, bir uygulamanın çalıştırılması ya da bir dosyanın indirilmesi. Bu olay, işletim sistemi, güvenlik duvarı veya bulut hizmeti tarafından kaydedilir. Ardından bu kayıtlar, SIEM veya EDR gibi güvenlik çözümlerine aktarılır.SOC ekipleri, binlerce farklı sistemden günde milyonlarca log alabilir. Bu logların büyük kısmı olağan ve beklenen işlemleri gösterirken, bazıları potansiyel tehditleri işaret eder. İşte bu noktada alarm (alert) devreye girer: belirli bir olay veya olaylar zinciri gerçekleştiğinde güvenlik sisteminin ürettiği uyarı.
Alarm sayesinde SOC analistleri milyonlarca ham log arasında kaybolmaz; yalnızca şüpheli ve anormal görünen olaylara odaklanır. Böylece günlük iş yükü milyonlarca log yerine sadece birkaç düzine alarmı incelemekle sınırlı kalır.
Uyarı Yönetim Platformları
| Çözüm | Örnekler | Açıklama |
|---|---|---|
| SIEM Sistemi | Splunk ES, Elastic | SIEM, güçlü uyarı yönetim yeteneklerine sahiptir ve çoğu SOC ekibi için ideal bir seçimdir. |
| EDR veya NDR | MS Defender, CrowdStrike | EDR ve NDR kendi uyarı panellerini sunsa da, genellikle SIEM veya SOAR kullanılması tercih edilir. |
| SOAR Sistemi | Splunk SOAR, Cortex SOAR | Daha büyük SOC ekipleri, birden fazla çözümden gelen uyarıları toplamak ve merkezileştirmek için SOAR kullanabilir. |
| ITSM Sistemi | Jira, TheHive | Bazı ekipler özel bir bilet yönetim (ITSM) sistemi kurarak özel çözümler kullanabilir. (Yukarıdaki GIF, ITSM ihtiyaçlarına uyarlanabilen basit bir araç olan Trello’dan alınmıştır.) |
Uyarı Triage Sürecinde L1’in Rolü
SOC ekibinde L1 analistleri, güvenliğin ön saflarında yer alır ve uyarılarla en yoğun şekilde çalışan kişilerdir. Günlük olarak sıfırdan yüzlere kadar değişebilen sayıda uyarı alabilirler; her biri potansiyel bir siber saldırının işareti olabilir. Ancak uyarı triage süreci yalnızca L1 analistleriyle sınırlı değildir, tüm SOC ekibi bu sürece katkı sağlar:- SOC L1 analistleri: Gelen uyarıları inceler, zararlı ile zararsızı ayırt eder ve gerçek tehdit durumunda L2 analistlerine yönlendirir.
- SOC L2 analistleri: L1’den gelen uyarıları detaylı şekilde analiz eder, kök neden araştırması yapar ve gerekli müdahaleleri gerçekleştirir.
- SOC mühendisleri: Uyarıların, analistler için yeterli ve doğru bilgi içermesini sağlar; böylece triage süreci daha verimli olur.
- SOC yöneticisi: Triage sürecinin hızını ve kalitesini takip eder, böylece kritik saldırıların gözden kaçmamasını garanti altına alır.
Uyarı Özellikleri
az çok aklımızda bir şeyler oturduğuna göre dostlarım bir uyarı özelliklerine bakalım beraber bu uyarı özelliklerinde fiks değişmez birkaç kural vardır bunları detaylı bir şekilde inceleyelim dostlarım| № | Mülk | Tanım | Örnekler |
|---|---|---|---|
| 1 | Uyarın Zamanı | Uyarının ne zaman üretildiğini gösterir. Çoğu durumda olayın gerçekleşmesinden birkaç dakika sonra tetiklenir. | - Uyarı Zamanı: 21 Mart, 15:35 - Olay Zamanı: 21 Mart, 15:32 |
| 2 | Uyarın Adı | Yaşanan durumu özetler ve genellikle tespit kuralının adıyla ilişkilidir. | - Alışılmadık Giriş Konumu - E-posta Kimlik Avı - Windows RDP Bruteforce - Olaso Veri Sızıntısı |
| 3 | Uyarın Şiddeti | Uyarının ne kadar acil olduğunu belirtir. İlk değerlendirme mühendisler tarafından yapılır, ancak analistler gerekirse değiştirebilir. | - ( ) Düşük / Bilgilendirici- (  ) Orta / Orta Derecede- (  ) Yüksek / Şiddetli- (  ) Kritik / Acil |
| 4 | Uyarın Durumu | Birinin uyarı üzerinde çalışıp çalışmadığını veya triage yapılıp yapılmadığını bildirir. | - ( ) Yeni / Atanmamış- (  ) Devam Ediyor / Beklemede- (  ) Kapalı / Çözüldü- Ve diğer özel durumlar |
| 5 | Uyarın Kararı | Uyarının gerçek bir tehdit mi yoksa yanlış bir alarm mı olduğunu açıklar. | - () True Olumlu / Gerçek Tehdit - ( ) False Pozitif / Tehdit Yok- Ve diğer geleneksel kararlar |
| 6 | Uyarın Atanan Kişi | Uyarıyı incelemek üzere atanan analisti gösterir. Bazen “uyarı sahibi” olarak da adlandırılır.İnceleme görevini üstlenen analisti belirtir. Bazen “uyarı sahibi” olarak da adlandırılır. | - Görevlendirilen kişi, ilgili uyarının sorumluluğunu taşır. |
| 7 | Uyarın Açıklaması | Uyarının neden üretildiğini ve hangi bağlamda önemli olduğunu anlatır. Genellikle üç bölümden oluşur: | - Uyarı oluşturma kuralının mantığı - Bu faaliyetin neden saldırı belirtisi olabileceği - İsteğe bağlı olarak önceliklendirme önerisi |
| 8 | Uyarın Alanları | Uyarıyı tetikleyen değerleri ve analistlerin yorumlarını içerir. | Etkilenen cihaz adı, girilen komut satırı ve duruma göre daha fazla bilgi. |
Genel olarak bu 8 madde üstüne SOC analistleri olayları değerlendirmektedir dostlarım A şirketindede çalışsanız B şirketindede temel mantık bunun üzerinedir
Uyarı Önceliklendirmesi:
bu kısımda ise hatırladığınız gibi dostlarım yüzlerce uyarı alıyoruz ama hangisinin daha kritik olduğunu bilmemiz gerekiyor. Ve genel olarak hangi uyarıda kornayı sonuna kadar çalacağımıza karar vermemize Uyarı önceliklendirme diyoruz ekranda yüzlerce uyarı varken tehdidin vaktinde tespit edilmesi bizim için kritik rol oynamaktadırÖnceliklendirme Mantığı
SOC ekipleri, hangi uyarının önce ele alınacağını belirlemek için kendi kurallarını oluşturur ve çoğu zaman bu süreci SIEM veya EDR üzerinde otomatik hale getirir. Genel yaklaşım ise şu mantığa dayanır:- Önce temiz bir liste oluştur Başka bir analistin üzerinde çalıştığı ya da zaten incelenmiş uyarılarla vakit kaybetme. Sadece yeni ve çözülmemiş uyarılar senin radarına girmeli.
- Ciddiyet sırasına göre ilerle Kritik uyarılar her zaman ilk sıradadır. Ardından yüksek, orta ve düşük seviyedekiler gelir. Bunun nedeni, kritik seviyedeki kuralların genellikle gerçek ve etkisi büyük tehditleri işaret etmesidir.
- Zaman faktörünü göz önünde bulundur Eski uyarılar yeni olanlardan önce incelenmelidir. Çünkü daha önce başlayan bir ihlal, saldırganın sistemden veri toplamaya başlamış olabileceğini gösterir; yeni uyarılar ise henüz ilk adımlarını atan bir girişimi işaret eder.
Uyarı Triyaj
İlk Adımlar
Bir uyarıyı üstlenirken yapılacak ilk şey, onun gerçekten senin sorumluluğunda olduğunu netleştirmektir. Başka analistlerin üzerinde çalıştığı uyarılara karışmamak için önce uyarıyı kendine ata, durumunu “Devam Ediyor” olarak güncelle ve ardından ayrıntılarını incele. Uyarının adı, açıklaması ve öne çıkan göstergeleriyle tanışmak, sonraki adımlar için hazırlık sağlar.İnceleme Süreci
Bu aşama en zahmetli kısımdır çünkü teknik bilgi ve deneyimini kullanarak olayın gerçek bir tehdit olup olmadığını anlaman gerekir. SIEM veya EDR kayıtlarını dikkatle analiz etmelisin. Bazı ekipler bu süreci kolaylaştırmak için çalışma kitapları (playbook/runbook) hazırlar. Eğer böyle bir kaynak yoksa şu noktalara odaklanabilirsin:- Hangi kullanıcı, sistem ya da servis risk altında? (ör. etkilenen kullanıcı, cihaz adı, bulut servisi, ağ veya web sitesi)
- Uyarıda hangi eylem tanımlanıyor? (ör. şüpheli giriş, zararlı yazılım, kimlik avı)
- Uyarının öncesinde veya sonrasında gerçekleşen olayları incele; olağan dışı hareketler var mı?
- Tehdit istihbaratı platformları veya diğer kaynaklarla bulgularını doğrula.
CW-Ommah...
Bug Researchers Tim Sundu.
Bug Researchers Tim Sundu.
Son düzenleme:
