Yükleniyor...
Yükleniyor...
Bir zafiyet bulunduğunda ne yapılacağı bellidir: yama uygulanır, bulgu kapanır. Sızdırılmış bir kullanıcı adı ve parola çiftinde ise yamalanacak bir şey yoktur. Sistem çalışıyor, yapılandırma doğru. Eksik olan tek şey, o parolanın artık sadece sizde olmamasıdır.
Bu yüzden sızıntı bulgusu zafiyet kuyruğuna konduğunda kaybolur. Aşağıda, Ornis Recon'un bu işi neden iki ayrı ekrana böldüğünü ve her alanın hangi kararı beslediğini inceliyoruz.
Kısa özet: Sızdırılmış kurumsal kimlik bilgisi yamayla değil; parola sıfırlama, oturum sonlandırma ve MFA zorlamasıyla kapatılır. Ornis Recon bu bulguyu Compromised Credentials ekranında maskelenmiş bir kayıt, Alerts ekranında ise kanıt dosyası ve MITRE etiketi taşıyan ayrı bir alarm olarak tutar.
Sızdırılmış kimlik bilgisi neden kendi kuyruğunu ister?
Sızıntı bulgusunun müdahalesi teknik değil kimlik tarafındadır: parola sıfırlama, aktif oturumların sonlandırılması ve çok faktörlü kimlik doğrulamanın (MFA) zorlanması. Bu üç adım birlikte yapılmazsa iş yarım kalır — parola değişse bile açık bir oturum çerezi saldırganı içeride tutmaya devam edebilir.
Eylemin sahibi de değişir. Yamayı sistem yöneticisi uygular; parola sıfırlamayı kimlik yönetimi ekibi yapar, kullanıcıyı bilgilendirir, çoğu zaman İK ve hukuk tarafını da haberdar eder.
Durum makinesi de farklıdır. Bir zafiyet "açık → devam ediyor → kapalı" hattında ilerler ve doğrulaması yeniden taramadır. Bir sızıntı kaydı ise kapatıldıktan sonra geçmişte kalır: aynı kullanıcı adı altı ay sonra başka bir kaynakta yeniden yayımlanabilir. Bu nedenle Ornis Recon'da Compromised Credentials ayrı bir modüldür; kendi STATUS alanına (new gibi) ve kendi filtre setine sahiptir.
Verizon 2026 DBIR'a göre çalınan kimlik bilgileri ilk erişim vektörleri içinde %13 payla ikinci sırada; 19 yılda ilk kez birincilikten düştü. Aynı rapor ihlallerin %62'sinde insan faktörünün rol aldığını gösteriyor — kimlik hattı, teknik yüzey küçülse bile açık kalmaya devam ediyor.
Compromised Credentials kaydında hangi alanlar var?
Ekran, bir sızıntı kaydını tek satırda karar verilebilir hâle getirecek alanları taşır: kimin, neyinin, hangi kaynaktan, ne kadar güvenle ve ne zaman göründüğü. Kullanıcı adı ve parola varsayılan olarak maskelidir; satır sonundaki göz ikonuyla açılır.
Ekranda Severity, Status, Type, Secret Type, Interface Type, Source ve History filtreleri bulunur. History filtresi pasifleştirilmiş kayıtları görünüme dâhil eder; "bu kullanıcı adı daha önce de sızmış mıydı?" sorusu tekrar eden sızıntıları görmek için önemlidir.
Parola alanı neden varsayılan olarak maskeli?
Çünkü bir güvenlik ekranı, ekipteki insanların dışında da izlenir. Bulgu inceleme oturumları paylaşılan ekranda yapılır, toplantılar kaydedilir, açık ofiste arkadan bakan biri olur. Varsayılanı "açık" yapan bir tasarım, sızmış bir parolayı ikinci kez sızdırma riskini araca yerleştirir.
Maskeleme aynı zamanda bir davranış tasarımıdır. Göz ikonuna basmak, analiste bilinçli bir seçim yaptırır: parolayı gerçekten görmesi mi gerekiyor, yoksa kullanıcı adı ve kaynak karar için yeterli mi? Vakaların çoğunda parolanın açılmasına gerek kalmaz; sıfırlama kararı için hesabın kimliği yeterlidir. Bu, verinin şifrelendiği anlamına gelmez — görünürlüğün varsayılan olarak kapalı olduğu anlamına gelir.
`TYPE` alanı employee ile customer'ı neden ayırır?
Aynı sızıntı kaydı, hesabın çalışana mı müşteriye mi ait olduğuna göre iki tamamen farklı süreci tetikler. Bir employee kaydı iç erişim sorunudur: kurumsal dizin hesabı, VPN, webmail, yönetim panelleri. Müdahale kurumun kendi kimlik sağlayıcısında biter.
Bir customer kaydı ise kişisel veri boyutunu açar. Etkilenen kişi kurum dışındadır; bilgilendirme, kayıt tutma ve mevzuat yükümlülüğü devreye girer. İki grup aynı kuyruğa aynı etiketle düşerse, bildirim penceresi sessizce kaçırılabilir. TYPE filtresi, bu iki işin birbirinin gürültüsü hâline gelmesini engeller.
Kayıt ne zaman alarma dönüşür? Alerts ekranı
Compromised Credentials ham bulguyu tutar; Alerts ise o bulgunun eyleme çağıran, referans verilebilir ve sınıflandırılmış hâlini üretir. Alarmın ayırt edici özelliği ORNIS-788 biçimindeki REF ID alanıdır: kaydın ömrü boyunca değişmeyen sabit bir kimlik.
Sabit kimliğin değeri iletişimdedir. Kurum bu numarayı kendi olay kaydında veya yazışmasında referans olarak kullanabilir; "geçen haftaki sızıntı bulgusu" gibi belirsiz ifadeler yerine tek bir kimlik üzerinden konuşulur.
Kuyruğu okunur kılan asıl alan SUBTYPE'dır. "company employee third party credentials exposed" ile "vulnerable technology detected on exposed company asset" aynı listede yan yana durur, ama biri kimlik ekibine diğeri sistem ekibine gider. CATEGORY alanının data / vulnerabilities ayrımı bu bölünmeyi filtreye dönüştürür.
`CONFIDENCE` neden `SEVERITY`den ayrı bir alan?
Çünkü "bu bulgu ne kadar kritik?" ile "bu bulgu ne kadar kesin?" iki farklı sorudur ve tek bir sayıya sıkıştırıldıklarında ikisi de kaybolur. Önem derecesi doğru çıktığı takdirde etkinin büyüklüğünü ölçer; güven skoru ise bulgunun gerçekten doğru olma ihtimalini ölçer.
Tek skorlu sistemlerde ikisi karışır. Düşük güvenli bir bulgu, yanlış pozitif yaratmamak için önem derecesi düşürülerek kuyruğa girer ve gerçek çıktığında geç fark edilir. Ya da yüksek etkili diye üst sıraya konur, birkaç kez boş çıkar, ekip o kategoriye güvenmeyi bırakır.
Ayrı tutulduklarında kuyruk dört köşeye açılır ve her köşenin farklı bir eylemi olur:
Sağ üst köşe, yanlış pozitif yönetiminin özüdür. %10 güvenle gelen bir "High" alarmı, %90 güvenle gelen bir "Medium" alarmın önüne koymak, ekibin zamanını doğrulanmamış bir bulguya harcatır. Tersi de yanlıştır: kesinliği yüksek diye düşük etkili bir bulgu kritik işin önüne geçmemelidir.
Pratik kural şudur: SEVERITY sıralamayı belirler, CONFIDENCE ise sıradaki işin ne olduğunu belirler — doğrudan müdahale mi, yoksa önce doğrulama mı.
MITRE ATT&CK etiketleri ne anlatır?
Alarmdaki `MITRE` alanı, bulguyu saldırganın hangi adımına karşılık geldiğiyle etiketler; böylece tekil bulgular ortak bir dile bağlanır. Sızıntı ve dış yüzey bulgularında görülen teknikler ağırlıklı olarak saldırının erken evrelerine düşer.
İlk üçünün Reconnaissance taktiğine düşmesi anlamlıdır: bunlar henüz bir saldırı değil, saldırıdan önceki hazırlığın kurumda bıraktığı izlerdir. Kapatıldıklarında bir istismar engellenmiş olmaz, istismarın hazırlığı zorlaştırılmış olur — "henüz bir şey olmadı" diye ertelenmelerinin nedeni de budur.
T1190 farklı bir kategoridedir. Initial Access taktiği, hazırlığın bittiği ve girişin denendiği andır. Bir kuyrukta her iki taktikten de bulgu varsa, Initial Access etiketli olan zaman baskısı taşır.
Alarm detayında ne var? Kanıt ve öneri
Alarm detayı, kararın gerekçesini ve kanıtını aynı ekranda tutar. Total Credentials kaç kimlik bilgisinin alarma dâhil olduğunu, Attachments ise kanıt dosyasını taşır — sızıntı alarmlarında bu dosya leaked_credentials.csv biçiminde görünür. Description bulguyu düz metinle anlatır, Recommendation önerilen adımı verir. Ekran Excel'e dışa aktarmayı destekler.
Kanıt dosyası iki işi çözer. Birincisi doğrulama: analist alarmın ne üzerine kurulduğunu kendi gözüyle görür. İkincisi kayıt tutma: bir bulgunun ne zaman, hangi içerikle tespit edildiğinin belgesi sonradan üretilemez.
KVKK bildirimi için hangi alanlar işe yarar?
Kişisel Verileri Koruma Kurulu'nun 24.01.2019 tarih ve 2019/10 sayılı kararına göre veri sorumlusu, ihlali öğrendiği andan itibaren gecikmeksizin ve en geç 72 saat içinde Kurul'a bildirim yapar. Sürenin ihlalin gerçekleştiği andan değil, öğrenildiği andan işlemesi belirleyicidir; dayanak 6698 sayılı Kanun'un 12/5 maddesidir. İlgili kişilere bildirim ise "makul olan en kısa sürede" yapılır.
Bu tanım tespit araçlarını doğrudan ilgilendirir: "öğrenme anı"nın belgelenebilmesi gerekir. Aşağıdaki eşleme, bildirimde cevaplanan soruların hangi alandan beslendiğini gösterir.
Sınır net söylenmeli: Ornis Recon hukuki uygunluk garantisi vermez. Bildirimin gerekip gerekmediğine, kapsamına ve zamanlamasına veri sorumlusu karar verir. Ürünün sağladığı şey karar değil, kararı destekleyen kanıt ve zaman damgasıdır.
Have I Been Pwned ile farkı nedir?
Have I Been Pwned bilinen bir adresin ihlal veri setlerinde geçip geçmediğini söyler; Ornis Recon'daki Compromised Credentials ise alan adı bazlı, bağlam taşıyan ve kuyruğa giren bir kayıt üretir. İkisi birbirinin yerine geçmez; farklı soruları yanıtlarlar.
Temel fark yön farkıdır: "bildiğim adres sızmış mı?" ile "hangi bilmediğim adres sızmış?" farklı araçlar ister.
Sınırlar da açık söylenmeli. Hiçbir izleme, henüz derlemelere düşmemiş bir sızıntıyı göremez. Ornis Recon bir kayıttaki parolanın hâlâ geçerli olup olmadığını da söylemez; bunu ancak kurumun kendi kimlik sağlayıcısı bilir. Ürün bulguyu, kaynağını, güven skorunu ve kanıtını verir — parola sıfırlama, oturum sonlandırma ve MFA zorlaması kurumun kendi sistemlerinde yapılır.
Sıkça sorulan sorular
Sızdırılmış kimlik bilgisi bulgusu neden zafiyet kuyruğunda takip edilmemeli?
Müdahalesi, sahibi ve doğrulaması farklıdır. Zafiyet yamayla kapanır ve yeniden taramayla doğrulanır; sızıntı ise parola sıfırlama, oturum sonlandırma ve MFA zorlamasıyla kapanır, doğrulaması kimlik sağlayıcıdadır. Ornis Recon bu nedenle Compromised Credentials'ı ayrı bir modül olarak tutar.
Parola alanı neden varsayılan olarak maskeli geliyor?
Güvenlik ekranları paylaşılan ekranda incelenir, toplantılarda kaydedilir ve açık ofiste izlenir. Varsayılanı açık bırakan tasarım, sızmış bir parolayı ikinci kez ifşa etme riskini araca yerleştirir. Maskeleme ayrıca analiste "bunu görmem gerekiyor mu?" sorusunu sordurur.
`CONFIDENCE` ile `SEVERITY` arasındaki fark pratikte nasıl kullanılır?
SEVERITY sıralamayı, CONFIDENCE ise sıradaki işin türünü belirler. Yüksek önem ve yüksek güven doğrudan müdahale demektir; yüksek önem ve düşük güven ise önce doğrulama demektir — kanıt dosyası açılır, kaynak ve tarih kontrol edilir, sonra karar verilir.
`TYPE` alanının `employee` veya `customer` olması neyi değiştirir?
employee kaydı iç erişim sorunudur ve kurumun kendi kimlik sistemlerinde çözülür. customer kaydı kişisel veri boyutunu açar: etkilenen kişiye bilgilendirme, kayıt tutma ve mevzuat yükümlülüğü gündeme gelir. İki grup aynı kuyrukta aynı aciliyetle işlenirse ikincisi gecikir.
`REF ID` alanı neden önemli?
ORNIS-788 biçimindeki REF ID, alarmın ömrü boyunca değişmeyen sabit bir kimliktir. Kurum bu numarayı kendi olay kaydında, yazışmasında veya değişiklik talebinde referans olarak kullanabilir; böylece aynı bulgu farklı ekiplerde farklı adlarla anılmaz.
Ornis Recon KVKK bildirimimi benim yerime yapar mı?
Hayır. Bildirimin gerekip gerekmediği, kapsamı ve zamanlaması veri sorumlusunun hukuki değerlendirmesidir. Ornis Recon bu değerlendirmeyi destekleyen girdileri sağlar: alarmın oluşturulma zamanı, LAST PUBLISHED tarihi, Total Credentials sayısı ve kanıt dosyası.
