Sessiz köşeler: 'biz her şeyi izliyoruz' yanılsaması
Salı sabahı 10:47. IT yöneticisi masasında SIEM ekranına bakıyor; yeşil metrikler, kaydırılan event akışı, son 7 günde 2,8 milyon satır log. "Her şey kontrol altında" diyor. Aynı gün 14:22'de finans ekibinden ticket geliyor: "NAS1'deki müşteri sözleşme klasörüne kimse erişemiyor, son 3 gündür dosyalar açılmıyor." IT masaya gidiyor, NAS'ı ping atıyor — cevap veriyor. Servisleri kontrol ediyor — SMB ayakta. Ama SIEM'e dönüp "NAS1" arattığında son event 11 gün öncesine ait. 11 gün boyunca o cihaz hiçbir log atmamış; kimse fark etmemiş. Çünkü dashboard yeşil, event sayısı yüksek, alarm yok. Bu senaryo Türkiye'deki yüzlerce orta ölçekli şirkette günlük yaşanıyor. IT ekibi "SIEM var, log topluyoruz" diyerek güvende hissediyor; oysa envanterin %30-40'ı ya hiç log atmıyor, ya credential eksik olduğu için agent bağlanamıyor, ya da ham SYSLOG_RAW formatında gelip classified edilmeden çöpe düşüyor. Sonuç: görünürlük boşlukları (visibility gaps). Saldırgan DC2'ye lateral movement yapıyor, ama DC2 log atmadığı için SIEM'de iz yok. Backup sunucusu 6 gündür failed, ama log gelmiyor — bunu öğrenmek için ya kullanıcı şikayet edecek ya da saldırgan ransomware tetikleyecek. ShamashAi bu sorunu "sayıya çeviriyor": envanterdeki her cihazı izliyor ve 5 farklı gap tipi tanımlıyor. Her gap'e critical/high/medium priority atıyor, remediation queue'sine düşüyor ve IT ekibine "şu 12 cihazın logu yok, şu 5 cihazın credential'ı eksik" diye somut liste veriyor. Bu yazıda ShamashAi'nin visibility gap mekanizmasını, tespitleri, önceliklendirmeyi ve remediation akışını teknik detaylarla anlatacağız.Neden "her şeyi görüyorum" yanılgısı oluşuyor?
Klasik SIEM dünyasında metrik mantığı şöyle işler: "Günde 2 milyon event geliyorsa, izleme yapıyoruz demektir." Ama bu event'ler envanterin %60'ından geliyorsa — mesela 100 cihazdan sadece 60'ı log atıyorsa — geri kalan 40 cihaz kör nokta oluyor. IT yöneticisi dashboard'a bakıp yeşil grafik gördüğünde, aslında hangi cihazların *sessiz* olduğunu göremez. İkinci sorun: credential rotasyonu. Bir domain admin şifresi değişti; ShamashAi agent eski credential ile DC'ye bağlanamıyor, ama bu durum "log yok" şeklinde pasif bir hata. Aktif alarm üretilmediği sürece IT ekibi fark etmiyor. Üçüncü sorun: parser eksikliği. Bazı cihazlar log atıyor ama ShamashAi parser engine onları tanımıyor; dolayısıyla event SYSLOG_RAW olarak ham tabloda duruyor, classified event'e dönüşmüyor. IT ekibi "log geliyor" sanıyor ama aslında kullanılabilir veri yok. Dördüncü sorun: health check timeout. Cihaz log atıyor ama son 10 dakikada health check sinyali gelmiyor — network gecikme, agent crash, servis restart gibi geçici sorunlar. Bu tür durumlarda cihaz "yarı-sessiz" durumda. Beşinci sorun: hiç görülmemiş cihazlar. Envantere eklendi, IP tanımlandı, ama kurulum tamamlanmadı ya da agent hiç deploy edilmedi. Kağıtta var, sistemde yok. ShamashAi bu 5 durumu ayrı ayrı tespit edip önceliklendirir. Böylece IT ekibi "nerede kör noktalarım var?" sorusuna sayısal yanıt alır.ShamashAi'nin 5 gap tipi ve detection mantığı
ShamashAi'nin Visibility modülü her 5 dakikada bir envanter taraması yapar ve aşağıdaki gap tiplerini tespit eder:1. never_seen — hiç event gelmemiş cihazlar
Tanım: Cihazdbo.devices tablosuna eklenmiş, ama dbo.events tablosunda hiç kayıt yok.
Tespit mantığı:
sql
SELECT d.device_id, d.hostname, d.ip_address, d.created_at
FROM dbo.devices d
LEFT JOIN dbo.events e ON d.device_id = e.device_id
WHERE e.event_id IS NULL
AND d.is_active = 1
AND DATEDIFF(HOUR, d.created_at, GETDATE()) > 2;
Bu sorgu, kurulumdan 2 saat geçmesine rağmen hiç event üretmemiş cihazları listeler. Örnek senaryo: dc03.afnteknoloji.local domain controller envantere eklendi, ama WinRM portu kapalı olduğu için agent bağlanamadı. ShamashAi bunu never_seen olarak işaretler ve critical priority verir — çünkü DC gibi kritik varlıkların görünmemesi büyük risk.
Remediation adımları:
- Agent deployment durumunu kontrol et (Windows:
Get-Service ShamashAgent, Linux:systemctl status shamashai-agent).
- Network bağlantısını test et (agent → SIEM server 5044 port).
- Credential doğruluğunu kontrol et (agent config dosyasında
api_keygeçerli mi?).
2. no_logs_24h — 24 saat sessiz
Tanım: Daha önce event göndermiş, ama son 24 saatte hiç log atmamış cihazlar. Tespit mantığı: sql SELECT d.device_id, d.hostname, MAX(e.timestamp) AS last_seen_at, DATEDIFF(MINUTE, MAX(e.timestamp), GETDATE()) AS minutes_silent FROM dbo.devices d INNER JOIN dbo.events e ON d.device_id = e.device_id WHERE d.is_active = 1 GROUP BY d.device_id, d.hostname HAVING DATEDIFF(HOUR, MAX(e.timestamp), GETDATE()) >= 24; Örnek:nas1.afn.local cihazı 3 gün önceye kadar SMB audit logu gönderiyordu, sonra kesildi. ShamashAi bunu high priority gap olarak işaretler. Olası sebepler:
- Agent servisi crash olmuş.
- Cihaz maintenance mode'a alınmış, IT ekibi bitirince agent'ı restart etmeyi unutmuş.
- Disk dolmuş, log rotation çalışmamış, agent log yazamıyor.
3. no_health_10m — health check timeout
Tanım: Event geliyor ama son 10 dakikada health check sinyali yok. ShamashAi agent'ları her 2 dakikada bir health beacon gönderiyor (event_type:AGENT_HEALTH_CHECK). Eğer 10 dakika boyunca bu beacon gelmezse, ama normal event'ler gelmeye devam ediyorsa, agent kısmi sorun yaşıyor demektir.
Tespit mantığı:
sql
SELECT d.device_id, d.hostname,
MAX(CASE WHEN e.event_type = 'AGENT_HEALTH_CHECK' THEN e.timestamp END) AS last_health,
MAX(e.timestamp) AS last_event
FROM dbo.devices d
INNER JOIN dbo.events e ON d.device_id = e.device_id
WHERE d.is_active = 1
GROUP BY d.device_id, d.hostname
HAVING DATEDIFF(MINUTE, MAX(CASE WHEN e.event_type = 'AGENT_HEALTH_CHECK' THEN e.timestamp END), GETDATE()) > 10
AND DATEDIFF(MINUTE, MAX(e.timestamp), GETDATE()) < 10;
Bu sorgu "genel event geliyor ama health check gelmiyor" durumunu yakalar. Priority: medium — acil değil ama agent stabilitesi şüpheli.
4. credential_missing — kimlik bilgisi eksik
Tanım: Cihaz tanımlı, ama ShamashAi agent'ının bağlanması için gerekli credentialdbo.devices tablosunda credential_status = 'missing' olarak işaretli.
Örnek: Yeni bir Fortigate firewall envantere eklendi, ama IT ekibi SNMP community string veya API token'ı girmedi. Agent bağlanamıyor.
Endpoint yanıtı:
javascript
{
"device_id": "e8c3b2d5-7a4f-4e9b-a1c6-9d8f3e2b7a4c",
"hostname": "fw02.afn.local",
"gap_type": "credential_missing",
"priority": "critical",
"credential_type": "snmp_v3",
"last_attempt": "2026-09-04T08:45:12Z",
"error_message": "Authentication failed: invalid community string"
}
Priority critical çünkü firewall gibi güvenlik cihazlarının logu olmadan SIEM anlamsız.
5. parser_raw_only — classify edilmemiş loglar
Tanım: Cihaz log gönderiyor, ama ShamashAi parser engine bu logu tanımıyor; eventdbo.events tablosunda event_type = 'SYSLOG_RAW' olarak duruyor.
Örnek: Üçüncü parti bir IoT gateway SYSLOG gönderiyor, ama ShamashAi'de parser yok. Bu loglar ham olarak saklanıyor ama korrelasyon, alarm, dashboard'da kullanılamıyor.
Tespit sorgusu:
sql
SELECT d.device_id, d.hostname, COUNT(e.event_id) AS raw_event_count
FROM dbo.devices d
INNER JOIN dbo.events e ON d.device_id = e.device_id
WHERE e.event_type = 'SYSLOG_RAW'
AND e.timestamp > DATEADD(DAY, -1, GETDATE())
GROUP BY d.device_id, d.hostname
HAVING COUNT(e.event_id) > 100;
Son 24 saatte 100'den fazla SYSLOG_RAW event üreten cihazlar listelenir. Priority: medium — log geliyor ama işlevsiz.
Remediation: IT ekibi ShamashAi destek'e örnek log gönderiyor, AfnTeknoloji parser ekliyor (genelde 3-5 iş günü). Alternatif: .NET 8 ile custom parser yazılıyor (ILogParser interface implement edilerek).
Priority matrisi ve remediation queue
ShamashAi her gap'e otomatik priority atar: | Gap tipi | Cihaz tipi | Priority | |-------------------|--------------------|----------| | never_seen | DC, Firewall, Core SW | critical | | never_seen | Printer, IoT | medium | | no_logs_24h | Critical asset | high | | no_logs_24h | Non-critical | medium | | credential_missing| Tüm cihazlar | critical | | no_health_10m | Tüm cihazlar | medium | | parser_raw_only | Tüm cihazlar | medium | Cihaz tipidbo.devices.criticality alanından okunur (IT ekibi kurulumda belirler).
Remediation queue: Her gap tespit edildiğinde dbo.visibility_gaps tablosuna yazılır:
sql
CREATE TABLE dbo.visibility_gaps (
gap_id UNIQUEIDENTIFIER PRIMARY KEY,
device_id UNIQUEIDENTIFIER,
gap_type NVARCHAR(50),
priority NVARCHAR(20),
detected_at DATETIME2,
resolved_at DATETIME2 NULL,
remediation_status NVARCHAR(20), -- pending, in_progress, resolved, ignored
assigned_to NVARCHAR(100) NULL,
notes NVARCHAR(MAX)
);
IT ekibi ShamashAi web panelinde "Visibility Gaps" sayfasına girdiğinde bu tablo görüntülenir. Her gap'e tıklayıp assigned_to alanına kendi adını yazabilir, remediation_status günceller. Çözüldüğünde (örneğin agent restart edilip log gelmeye başladığında) ShamashAi otomatik resolved_at timestamp'i yazar.
Örnek kullanım: 50 cihazlık bir şirkette gap tespiti
Senaryo: AfnTeknoloji, İstanbul'da 50 çalışanlı bir yazılım şirketi. Envanter:- 2 DC (dc01, dc02)
- 1 Fortigate firewall
- 3 core switch (Cisco)
- 1 NAS (Synology)
- 40 endpoint (Windows + macOS)
- 3 Linux sunucu
GET /visibility-gaps endpoint'ini sorguluyor:
bash
curl -X GET https://siem.afn.local/api/visibility-gaps \
-H "Authorization: Bearer {api_key}" \
-H "Content-Type: application/json"
Yanıt:
{
"gaps": [
{
"device_id": "a1b2c3d4",
"hostname": "dc02.afn.local",
"gap_type": "never_seen",
"priority": "critical",
"last_seen_at": null,
"remediation_status": "pending"
},
{
"device_id": "e5f6g7h8",
"hostname": "nas1.afn.local",
"gap_type": "no_logs_24h",
"priority": "high",
"last_seen_at": "2026-09-01T19:30:00Z",
"minutes_silent": 3885
},
{
"device_id": "i9j0k1l2",
"hostname": "sw-core-03",
"gap_type": "credential_missing",
"priority": "critical",
"credential_type": "snmp_v2c"
},
{
"device_id": "m3n4o5p6",
"hostname": "iot-gateway-01",
"gap_type": "parser_raw_only",
"priority": "medium",
"raw_event_count": 1247
}
],
"total": 4,
"critical_count": 2,
"high_count": 1,
"medium_count": 1
}
IT ekibinin aksiyonları:
1. dc02 (never_seen): IT masaya gidiyor, Get-Service ShamashAgent çalıştırıyor — servis stopped. Manuel start ediyor, 2 dakika sonra event gelmeye başlıyor. Gap otomatik resolved.
2. nas1 (no_logs_24h): NAS web arayüzüne giriyor, syslog ayarlarını kontrol ediyor — syslog hedefi yanlış IP. Düzeltiyor, test log gönderiyor. 5 dakika sonra ShamashAi event alıyor, gap resolved.
3. sw-core-03 (credential_missing): Switch SNMP community string'i unutulmuş. ShamashAi panelinde cihaz ayarlarına girip snmp_community: public ekliyor. Agent SNMP polling başlatıyor, loglar geliyor.
4. iot-gateway-01 (parser_raw_only): IT destek ticket açıyor, örnek log gönderiyor. AfnTeknoloji ekibi 4 iş gününde custom parser ekliyor, sonraki deployment'ta aktif oluyor.
Sonuç: 4 gap'ten 3'ü 1 saat içinde çözüldü, 1'i parser desteği bekleniyor. Artık envanterin %100'ü görünür.
Dashboard ve otomatik bildirimler
ShamashAi web panelinde "Visibility Coverage" widget'ı:- Total devices: 50
- Sending logs (last 1h): 47
- Gaps detected: 3
- Coverage ratio: 94%
dbo.soar_actions tablosuna yazılır, mail gateway üzerinden IT ekibine gönderilir.
KVKK Madde 12 uyumluluğu ve audit trail
KVKK Madde 12 (Veri Güvenliği) uyarınca işlenen kişisel verilerin "hukuka aykırı erişimi önlemek" için teknik tedbirler alınmalı. Eğer bir cihaz log atmıyorsa, o cihazda gerçekleşen erişimleri tespit edemezsiniz — yani KVKK uyumluluğu zayıflar. ShamashAi visibility gap verilerinidbo.audit_log tablosuna kaydeder:
sql
INSERT INTO dbo.audit_log (event_type, user_id, details, timestamp)
VALUES ('VISIBILITY_GAP_DETECTED', 'system',
'{"device": "dc02", "gap_type": "never_seen", "priority": "critical"}',
GETDATE());
Denetim sırasında "hangi cihazların ne zaman sessiz kaldığını, ne zaman düzeltildiğini" kanıtlamak için bu tablo ISO 27001:2022 Annex A.12.4.1 (event logging) kapsamında sunulur.
Limitler ve dürüst notlar
- Parser geliştirme süresi: Desteklenmeyen cihaz için custom parser 3-5 iş günü sürebilir; acil durumlarda pilot kapsamında öncelik verilebilir.
- Agent deployment sorumluluğu: ShamashAi agent'ın cihaza kurulmasını otomatik yapmaz; IT ekibi GPO, Ansible veya manuel yöntemle deploy etmeli.
- Cloud SaaS kaynaklar: Microsoft 365, Google Workspace gibi SaaS logları API üzerinden alınır; visibility gap tespiti sadece API credential'ı eksikse çalışır, SaaS tarafında log retention ayarlarını kontrol edemeyiz.
- Network device credential rotasyonu: Switch/firewall credential'ı değiştiğinde ShamashAi manuel güncelleme gerektirir; otomatik credential sync yok (roadmap'te 2027 Q1).
- Gap çözümü garanti değil: ShamashAi gap'i tespit eder, remediation sorumluluğu IT ekibindedir; "otomatik düzelt" özelliği sadece basit durumlar için var (örneğin agent service restart).
Pilot programı 30 gün ücretsiz: shamashai.com.tr/iletisim