Bir SOC ekibine "SIEM'inizi değiştirmeyi düşünüyor musunuz?" diye sorduğunuzda alacağınız en yaygın cevap genelde teknik bir gerekçe değil, duygusal bir refleks olur: "Şu an bir sorun yaşamıyoruz, neden riske girelim?" Bu refleks aslında mantıksız değil — güvenlik ekipleri risk almamayı meslek olarak yapıyor. Ancak burada gözden kaçan bir nokta var: hiçbir şey değiştirmemek de bir risk kararıdır, sadece görünmeyen ve fatura edilmeyen bir risk. Özellikle mevcut sistem yurt dışı merkezli, dolar bazlı lisanslı bir yabancı SIEM ise bu risk her geçen yıl büyüyor.

Bu yazıda, "çalışan sistemi bozma" korkusunun nereden geldiğini, bu korkunun gerçekte ne kadarının haklı olduğunu ve yerli bir SIEM'e, OrianaLOG ve üzerine kurulu OrianaSIEM katmanına geçişin, güvenlik görünürlüğünde kesinti yaratmadan nasıl yönetilebileceğini adım adım ele alıyoruz.

1. "Çalışıyor" Kelimesinin Arkasındaki Görünmeyen Maliyet

Mevcut bir sistemi korumak kararı, çoğu zaman "maliyetsiz" bir seçenek gibi görünür. Oysa değişmemenin de bir bedeli vardır; sadece bu bedel fatura üzerinde değil, biriken risk üzerinde görülür — ve bu kalemlerin dördü de doğrudan yerli bir SIEM'e geçişle ortadan kalkıyor:

• Dolar/euro bazlı lisanslama modelinde kur dalgalanmaları, güvenlik bütçesini yıl içinde öngörülemez hale getirebiliyor.
• 7545 sayılı Siber Güvenlik Kanunu kapsamında yetkilendirilmiş tedarikçi ve yerli/millî ürün önceliği ilkesi, kritik altyapı statüsündeki kurumlar için tedarik sürecini doğrudan etkiliyor.
• Yurt dışı merkezli destek hatlarında zaman dilimi ve dil bariyeri, kritik bir olay anında dakikaların kaybına yol açabiliyor.
• Log hacmi büyüdükçe eski platformun ölçeklenme ve maliyet sınırlarına yaklaşması. ​

Bu kalemlerin her birini önceki yazılarımız olan "Yerli SIEM Kullanan Kurumlar Ne Kazanır?" ve "Türkiye'de Siber Güvenlik Mevzuatı ve Yerli SIEM" başlıklı yazılarımızda ayrıntılarıyla ele almıştık. Buradaki nokta şu: "değişmeme" kararı da aktif olarak seçilmiş bir risk profilidir; sadece bu risk, bir fatura ya da bir denetim raporuna düşene kadar görünmez. Yerli ve TL bazlı lisanslanan OrianaLOG, bu kalemleri baştan devre dışı bırakan bir konumda. “What Do Institutions That Use a Domestic SIEM Gain?” ​ “Cybersecurity Legislation in Turkey and Domestic SIEM.” ​

2. Geçişte Asıl Korkulan Şey Ne?

SIEM geçişine direnç genelde tek bir korkudan değil, birbirine bağlı birkaç somut endişeden besleniyor:

• Görünürlük kaybı: Geçiş sırasında bir log kaynağının veya ayrıştırma (parsing) kuralının atlanması, geçici bir kör nokta yaratabilir.
• Alarm ve kural kaybı: Yıllar içinde ince ayar yapılmış korelasyon kurallarının yeni platformda sıfırdan yazılması gerektiği düşüncesi.
• Ekip öğrenme eğrisi: Analistlerin mevcut arayüze ve sorgu diline aşina olması, yeni bir platformda üretkenlik kaybı yaşanacağı korkusunu besliyor.
• Uyumluluk raporlama boşluğu: Denetimlerde kullanılan hazır raporların yeni sistemde aynı formatta üretilip üretilemeyeceği belirsizliği.

Bu endişelerin çoğu gerçek, ama çözümsüz değil. Yakın zamanlı SIEM geçiş rehberlerinin ortak vurgusu, modern platformların ham log sorgulamak yerine bağlamlandırılmış, önceliklendirilmiş uyarılar sunacak şekilde tasarlandığı ve bunun öğrenme eğrisini genellikle beklenenden daha kısa kıldığı yönünde. OrianaLOG'un One Shot Correlation yaklaşımı — çok adımlı, birbirine bağımlı kural zincirleri yerine tek kural—tek olay—tek tetikleme mantığı — burada özellikle işe yarıyor: geçiş ekibi, eski platformdaki karmaşık, katmanlı korelasyon senaryolarının tamamını birebir yeniden kurmak zorunda kalmadan, temel ama kritik tehdit senaryolarını (yetkisiz erişim, başarısız oturum denemeleri, ransomware belirtileri) hızlıca ayağa kaldırabiliyor; daha derin davranışsal analiz ihtiyacı ise OrianaSIEM katmanındaki UEBA ve risk skorlamasıyla kademeli olarak eklenebiliyor.

3. Paralel Çalışma Modeli: Riski Neredeyse Sıfıra İndiren Yöntem

SIEM geçiş projelerinde artık standart hâline gelmiş yaklaşım, "anahtar teslim" bir geçiş değil, paralel çalışma (parallel run) modelidir. Mantık basit: eski sistem kapatılmadan yeni sistem devreye alınır, iki platform belirli bir süre yan yana çalışır ve sonuçlar karşılaştırılır.

Bu modelin sağladığı somut fayda, bir geçiş sektör rehberlerinde şu şekilde özetleniyor: paralel hat çalıştırmadan yapılan bir geçiş, kesintiye kadar veri boşluklarını, bozuk ayrıştırıcıları veya hatalı yapılandırılmış alarmları görünmez kılma riski taşıyor; paralel çalışma ise sorunları erken tespit etmeyi, yeni sistemi ince ayarlamayı ve trafiği kademeli olarak artırmayı mümkün kılıyor.

Bir başka geçiş rehberi de aynı noktayı vurguluyor: amaç, üretime geçiş (cutover) öncesinde yeni platformun beklendiği gibi çalıştığına dair güven oluşturmak amacıyla iki SIEM platformunu eş zamanlı çalıştırarak operasyonel riski en aza indirmek. ​

Kritik bir disiplin notu: paralel çalışma dönemi için baştan net bir bitiş tarihi (sunset date) belirlenmeli. Açık uçlu bırakılan paralel çalışma dönemleri, planlanandan neredeyse her zaman daha uzun sürüyor ve iki sistemi aynı anda işletmenin gizli maliyetini büyütüyor.

3.1 OrianaLOG'un Esnek Kurulum Seçenekleri Paralel Çalışmayı Neden Kolaylaştırıyor

Paralel çalışma modelinin en büyük pratik engeli genelde altyapı: yeni sistemi eskiyle çakışmadan, ek bir bütçe kalemi açmadan nasıl ayağa kaldırırsınız? OrianaLOG'un multi-platform mimarisi ve on-premise, cloud, appliance ve Docker desteği tam olarak bu noktada devreye giriyor: veri egemenliğinin öncelikli olduğu kamu/finans/kritik altyapı kurumları on-premise kurulumla başlayabilirken, hızlı başlangıç isteyen ekipler cloud seçeneğiyle, konteyner tabanlı altyapısı olan kurumlar ise Docker desteğiyle paralel çalışma ortamını günler içinde kurabiliyor — bu da 3-4 haftalık entegrasyon testi aşamasını önemli ölçüde kısaltıyor.

4. Adım Adım Geçiş Takvimi (OrianaLOG/OrianaSIEM'e Geçiş)

Geçiş süreci kurumun ölçeğine göre değişse de, orta ölçekli bir kurum için tipik bir SIEM geçişinin uçtan uca yaklaşık 12 hafta sürdüğü ve şu aşamalardan geçtiği belirtiliyor: keşif ve envanter çıkarma, mimari tasarım, veri hattı (pipeline) kurulumu, tespit/korelasyon kurallarının taşınması, paralel çalışma ve doğrulama penceresi, kademeli cutover ve cutover sonrası optimizasyon; her aşamada bir geri dönüş (rollback) noktası bulunuyor.

Bu çerçeveyi kendi kurumunuza uyarlarken izleyebileceğiniz basit bir taslak:

• 1-2. Hafta — Envanter ve önceliklendirme: Mevcut log kaynaklarının, korelasyon kurallarının ve uyumluluk raporlarının tam listesi çıkarılır; hangi kaynağın kritik, hangisinin düşük riskli olduğu sınıflandırılır.
• 3-4. Hafta — Düşük riskli kaynaklarla entegrasyon testi: Kritik olmayan log kaynakları önce yeni sisteme bağlanır; parser ve alarm davranışı test edilir.
• 5-8. Hafta — Paralel çalışma: Kritik log kaynakları da devreye alınır; iki sistem eş zamanlı çalışır, alarm ve rapor çıktıları karşılaştırılır.
• 9-10. Hafta — Kademeli cutover: Güven kazanılan kaynaklar sırayla eski sistemden ayrılıp yeni sisteme taşınır.
• 11-12. Hafta — Optimizasyon ve arşivleme: Eski sistem, yasal saklama süresi dolana kadar salt-okunur arşiv modunda tutulur; yeni sistemde kural ince ayarı sürdürülür.

Bu takvim sabit bir kural değil, bir başlangıç noktası; kurumun log hacmi ve ekip kapasitesine göre daralıp genişleyebilir.

5. Geçiş Sırasında Gözden Kaçırılmaması Gerekenler

• Uyumluluk eşleştirme matrisi: Denetimde istenen her raporun, hangi mevzuata (7545, KVKK, BDDK/SPK, 5651) karşılık geldiğini ve yeni platformda eşdeğerinin bulunup bulunmadığını gösteren bir liste çıkarılmalı; bu liste paralel çalışma döneminde doğrulama kontrol listesine dönüşür.
• Otomatik yanıt aksiyonları önce izleme modunda: Firewall engelleme veya hesap kilitleme gibi otomatik SOAR aksiyonları, tespit paritesi doğrulanana kadar yeni platformda sessizce (audit-only) çalıştırılmalı; sessiz başarısızlık riski en yüksek alan burasıdır.
• Geri dönüş (rollback) noktaları: Her aşamada, bir sorun çıkarsa önceki duruma dönebileceğiniz açık bir plan olmalı.
• Sabit bir bitiş tarihi: Paralel çalışma dönemi için net bir sunset date belirlenmeli; aksi halde iki sistemi birlikte işletmenin depolama ve lisans maliyeti sessizce büyür.
• Haftalık tespit performansı takibi: Ortalama tespit süresi (MTTD) gibi temel göstergeler, paralel çalışma boyunca haftalık olarak karşılaştırılmalı.

6. Her Zaman Acele Etmek Doğru mu?

Bu yazının amacı geçişi körü körüne teşvik etmek değil. Bazı durumlarda beklemek gerçekten doğru karardır: yaklaşan bir denetim döneminin ortasında, kritik bir proje teslim tarihine çok yakın bir zamanda veya geçişi yönetecek asgari ekip kapasitesi henüz yoksa, geçişi bir sonraki uygun pencereye planlamak daha sağlıklı olabilir.

Ancak burada ayırt edilmesi gereken şey, "doğru zamanı beklemek" ile "hiç planlamamak" arasındaki fark. Birincisi bir strateji, ikincisi ise statüko önyargısının kararı sizin adınıza vermesine izin vermektir.

Sonuç: Risk, Değişmemekte de Var — Sadece Görünmüyor

"Bozuk değilse dokunma" refleksi, güvenlik dünyasında haklı bir temkinlilikten doğuyor. Ama bir SIEM geçişinde asıl soru "risk var mı?" değil, "riski nasıl görünür ve yönetilebilir kılarım?" sorusu olmalı. Paralel çalışma modeli, kademeli cutover ve net rollback noktalarıyla planlanan bir geçiş, güvenlik görünürlüğünde kesinti yaratmadan yürütülebilir — ve bu geçiş yerli bir platforma, OrianaLOG ve OrianaSIEM'e yapıldığında, kur riski ve yurt dışı veri aktarımı gibi ek risk katmanları da baştan devre dışı kalıyor.

Özetle, yabancı bir SIEM'den OrianaLOG/OrianaSIEM'e geçiş, "her şeyi bir günde değiştirme" riski taşımıyor: esnek kurulum seçenekleri (on-premise, cloud, appliance, Docker) sayesinde paralel çalışma ortamı hızlıca kurulabiliyor, One Shot Correlation yaklaşımı temel tehdit senaryolarını erkenden ayakta tutuyor, ihtiyaç büyüdükçe de UEBA, MITRE ATT&CK uyumu ve SOAR entegrasyonuyla OrianaSIEM katmanına kademeli olarak geçilebiliyor.

Kurumunuz için OrianaLOG/OrianaSIEM'e geçişin nasıl bir takvime oturacağını görmek isterseniz, mevcut log kaynaklarınızın envanterini birlikte çıkarabileceğimiz bir demo talebi veya POC görüşmesi, bu sürecin en risksiz başlangıç noktasıdır.

Sık Sorulan Sorular

SIEM geçişi sırasında log kaybı yaşanır mı?

Doğru planlanmış bir paralel çalışma döneminde log kaybı riski çok düşüktür; çünkü eski sistem, yeni sistem doğrulanana kadar veri toplamaya devam eder. Risk, paralel çalışma adımı atlanıp doğrudan tek seferlik bir geçiş ("big bang") yapıldığında artar.

Ekip yeni platforma ne kadar sürede adapte olur?

Bu, ekibin deneyimine ve platformun tasarımına göre değişir; ancak bağlamlandırılmış ve önceliklendirilmiş uyarılar sunan modern platformlarda öğrenme eğrisinin, ham sorgu diline dayanan eski araçlara göre daha kısa olduğu genel bir gözlem.

Eski sistemdeki geçmiş loglar yeni sisteme taşınmak zorunda mı?

Zorunlu değil; çoğu kurum, yasal saklama süresi dolana kadar eski sistemi salt-okunur arşiv modunda tutmayı, yeni veriyi ise doğrudan yeni platformda toplamayı tercih ediyor.

Paralel çalışma dönemi ne kadar sürmeli?

Kurumun ölçeğine göre değişir; orta ölçekli bir kurumda birkaç haftalık bir doğrulama penceresi tipik olsa da, önemli olan süreden çok, baştan belirlenmiş sabit bir bitiş tarihinin olması.