Perşembe 17:48: Sophos firewall'un log formatı değişti, tüm alarm kuralları bozuldu
Sistem yöneticisi ticket açmış: "Sophos geçen hafta firmware güncelledi, artık 'threat blocked' mesajında port numarası 4. kolondan 6. kolona geçmiş. 18 korelasyon kuralımız src_port alanını okumuyor, tüm port-taraması alarmları sustu. Yeniden yazılması 3-4 gün sürer." Aynı hafta içinde Fortinet, CEF formatından JSON'a geçmeye karar vermiş; 40 satırlık regex kurallarını yeniden yazman gerekiyor. Bir ay sonra Windows Event 4625 içinde yeni bir alan ekleniyor, Elastic mapping'i güncellemek için downtime planlıyorsun. Bu senaryolar yalnız değil: ortalama SIEM operasyonu zamanının %30'u vendor formatı değişikliklerine uyum çalışması ile harcanıyor. ShamashAi bu sorunu kanonik şema ile çözüyor: her vendor'ın logu ingest anında aynı yapıya dönüştürülür, risk motoru + korelasyon kuralları + dashboard sorguları bu şema üzerinde çalışır. Vendor formatı değiştiğinde yalnızca parser satırı güncellenir, hiçbir kural değişmez.
Kanonik şema nedir ve ShamashAi nasıl kullanıyor?
Kanonik şema, farklı veri kaynaklarından gelen olayları tek bir standart yapıya dönüştüren normalizasyon modelidir. ShamashAi, OCSF (Open Cybersecurity Schema Framework) mimarisinden ilham alarak (tam uyumluluk değil, ihtiyaç odaklı alt küme) ~30 event_type tanımlar ve tüm logları bu tiplere eşler. Her event, dbo.events tablosuna yazılmadan önce şu alanlarla normalleştirilir:
sql CREATE TABLE dbo.events ( id bigint IDENTITY PRIMARY KEY, tenant_id int NOT NULL, event_type varchar(64) NOT NULL, -- AUTH_FAIL_USER, BRUTE_FORCE_DETECTED, M365_RISKY_SIGNIN... severity varchar(16) NOT NULL, -- info, low, medium, high, critical timestamp datetime2 NOT NULL, src_ip varchar(45), dst_ip varchar(45), [user] nvarchar(128), device_id int, action varchar(32), -- allow, deny, quarantine, delete... message nvarchar(max), raw_log nvarchar(max), INDEX ix_tenant_ts NONCLUSTERED (tenant_id, timestamp DESC), INDEX ix_severity NONCLUSTERED (severity, timestamp DESC), INDEX ix_device NONCLUSTERED (device_id, timestamp DESC), INDEX ix_event_type NONCLUSTERED (event_type, timestamp DESC) );
Bu yapıyı kullanarak bir Sophos firewall "threat detected" mesajı şöyle dönüştürülür:
Sophos raw log (eski format):
2026-10-14T09:03:11 device=XG450 log_type=Firewall action=deny src=172.16.10.45 dst=8.8.8.8 src_port=54321 dst_port=53 threat=DNS_Tunneling
ShamashAi kanonik event:
{ "event_type": "KNOWN_BAD_IP", "severity": "high", "timestamp": "2026-10-14T09:03:11Z", "src_ip": "172.16.10.45", "dst_ip": "8.8.8.8", "user": null, "device_id": 8, "action": "deny", "message": "Sophos XG450: DNS_Tunneling engellenmiş", "raw_log": "2026-10-14T09:03:11 device=XG450 log_type=Firewall action=deny src=172.16.10.45 dst=8.8.8.8 src_port=54321 dst_port=53 threat=DNS_Tunneling" }
Aynı mantık Windows Event 4625, Palo Alto, FortiGate, M365 Risky Sign-in, AWS GuardDuty için de uygulanır. Her vendor'ın parser'ı farklı olsa da çıktı şeması aynıdır.
30 kanonik event_type ve severity eşleme
ShamashAi şu anda 30 event_type tanımlıyor; pilot sürecinde müşteri ihtiyacına göre genişletilebilir. Sık kullanılanlar:
- AUTH_FAIL_USER: kullanıcı adı/şifre hatası (RDP, SSH, web, AD)
- BRUTE_FORCE_DETECTED: eşik aşıldığında (örnek: 5 dakikada 10 başarısız deneme)
- M365_RISKY_SIGNIN: Microsoft Identity Protection risky user/location alert
- KNOWN_BAD_IP: threat-intel match (Tor exit node, botnet C2, AbuseIPDB score > 90)
- BEHAVIORAL_ANOMALY:
dbo.behavior_baselinestablosundan sapma (olağan dışı saat/coğrafya) - CERT_EXPIRING: SSL/TLS sertifikası <30 gün
- SOAR_ACTION: otomasyon tetiklendi (örnek: IP block, hesap kilitle)
- BACKUP_FAILED: Veeam, Windows Backup, Acronis hata kodu
- FIREWALL_DENY: ACL deny, IPS drop
- MALWARE_DETECTED: EDR/antivirus alert
- DATA_EXFILTRATION_RISK: büyük dosya transferi (>500 MB) veya olağan dışı upload
- PRIVILEGE_ESCALATION: sudo, runas, UAC prompt
- CONFIG_CHANGE: firewall kural değişimi, GPO update, router config
- COMPLIANCE_VIOLATION: ISO 27001 veya KVKK madde 12 gereksinimlerine uyumsuzluk (ör. şifreleme kapalı dosya)
javascript // Node.js Fastify route: /ingest/parse const severityMap = { AUTH_FAIL_USER: (count) => (count > 5 ? 'medium' : 'low'), BRUTE_FORCE_DETECTED: () => 'high', M365_RISKY_SIGNIN: () => 'high', KNOWN_BAD_IP: (threatScore) => (threatScore > 90 ? 'critical' : 'high'), BEHAVIORAL_ANOMALY: () => 'medium', CERT_EXPIRING: (daysLeft) => (daysLeft < 7 ? 'high' : 'medium'), BACKUP_FAILED: () => 'medium', };
function assignSeverity(eventType, metadata) { const fn = severityMap[eventType]; return fn ? fn(metadata) : 'info'; }
Bu sayede korelasyon motorunun sorgusu şöyle sadeleşir:
sql -- Korelasyon: 10 dakika içinde aynı user'dan 3+ farklı event_type SELECT [user], COUNT(DISTINCT event_type) AS type_count FROM dbo.events WHERE tenant_id = @tenantId AND timestamp > DATEADD(MINUTE, -10, GETDATE()) AND severity IN ('medium','high','critical') GROUP BY [user] HAVING COUNT(DISTINCT event_type) >= 3;
Vendor formatı değiştiğinde bu SQL sorgusu hiç değişmez. Yalnızca ilgili parser güncellenir.
Parser güncellemesi: tek satır, sıfır downtime
Sophos firmware 20.0.5'te port alanı 4. kolondan 6. kolona geçtiğinde ShamashAi'da yapılan değişiklik:
Eski parser (parsers/sophos.js): javascript function parseSophos(line) { const parts = line.split(' '); const srcPort = parts[3].split('=')[1]; // eski konum // ... }
Yeni parser: javascript function parseSophos(line) { const parts = line.split(' '); const srcPort = parts[5].split('=')[1]; // yeni konum // ... }
Değişiklik git'e commit edilir, Next.js web panel üzerinden "Parser Modülü > Sophos > Güncelle" butonuna basılır. ShamashAi .NET agent'ları yeni parser'ı pull eder (hot-reload, restart gerektirmez). Tüm korelasyon kuralları, dashboard widget'ları, compliance raporu sorguları kanonik şema üzerinde çalıştığı için etkilenmez.
Bir başka senaryo: Fortinet CEF'ten JSON'a geçiyor. Yeni parser:
javascript // parsers/fortinet.js function parseFortigate(rawLog) { let obj; if (rawLog.startsWith('{')) { obj = JSON.parse(rawLog); // yeni format } else { obj = parseCEF(rawLog); // eski format (geçiş döneminde ikisi de çalışır) } return { event_type: mapFortiEventType(obj.subtype), severity: mapFortiSeverity(obj.level), src_ip: obj.srcip, dst_ip: obj.dstip, user: obj.user || null, action: obj.action, message: obj.msg, raw_log: rawLog, }; }
Hibrit parser, geçiş döneminde her iki formatı da kabul eder. Kural motoru değişiklikten etkilenmez.
Hot-path query performansı: 4 indeks, milisaniye seviyesinde
dbo.events tablosunda 4 indeks tanımlı:
1. ix_tenant_ts: (tenant_id, timestamp DESC) — multi-tenant mimaride tenant izolasyonu + zaman tabanlı sorgular 2. ix_severity: (severity, timestamp DESC) — "son 24 saatte high/critical eventler" widget'ı 3. ix_device: (device_id, timestamp DESC) — cihaz bazlı timeline 4. ix_event_type: (event_type, timestamp DESC) — "BRUTE_FORCE_DETECTED son 1 saat" alarmı
Dashboard'da en sık kullanılan hot-path sorgu:
sql SELECT TOP 100 id, event_type, severity, src_ip, dst_ip, [user], timestamp, message FROM dbo.events WITH (NOLOCK) WHERE tenant_id = @tenantId AND severity IN ('medium','high','critical') AND timestamp > DATEADD(HOUR, -24, GETDATE()) ORDER BY timestamp DESC;
Test ortamında (100 cihaz, günlük ~500K event) bu sorgu 2-4 ms döner. İndeks ix_severity seek + timestamp range scan ile optimize edilir. SQL Server execution plan:
Index Seek (ix_severity) → Key Lookup (clustered PK) → Top 100 Estimated Subtree Cost: 0.0084
Aynı mantıkla korelasyon motoru her 60 saniyede şu sorguları çalıştırır:
sql -- Brute force tespit (aynı src_ip'den 5 dakikada 10+ AUTH_FAIL_USER) SELECT src_ip, COUNT(*) AS fail_count FROM dbo.events WHERE tenant_id = @tenantId AND event_type = 'AUTH_FAIL_USER' AND timestamp > DATEADD(MINUTE, -5, GETDATE()) GROUP BY src_ip HAVING COUNT(*) >= 10;
Eğer eşik aşılırsa yeni event yaratılır: event_type = 'BRUTE_FORCE_DETECTED', severity = 'high' ve dbo.soar_actions tablosuna IP block talimatı eklenir:
sql INSERT INTO dbo.soar_actions (tenant_id, action_type, target, status, created_at) VALUES (@tenantId, 'BLOCK_IP', @srcIp, 'pending', GETDATE());
SONRA otomation engine (Node.js worker) bu talimatı alıp POST /soar/block endpoint'ine gönderir:
javascript // Node.js Fastify route fastify.post('/soar/block', async (req, reply) => { const { tenant_id, target_ip } = req.body; // Firewall API çağrısı (Sophos, Fortinet, Palo Alto...) await firewallService.blockIP(tenant_id, target_ip); await db.query( 'UPDATE dbo.soar_actions SET status = @status, executed_at = GETDATE() WHERE target = @target', { status: 'completed', target: target_ip } ); return { success: true }; });
OCSF ilhamı, tam uyumluluk değil
Open Cybersecurity Schema Framework (OCSF), AWS, Splunk, IBM'in ortak yürüttüğü açık standarttır. ShamashAi, OCSF'nin temel prensiplerini (normalize event, vendor-agnostic schema, extensible taxonomy) benimser, ancak tam JSON-LD uyumluluğu hedeflemez. Nedenleri:
1. OCSF 40+ sınıf, 200+ attribute içerir. Orta ölçekli Türk firmaları için %80'i gereksiz (örneğin "satellite telemetry", "container orchestration"). 2. SQL Server'da nested JSON sorguları yavaş. ShamashAi düz tablo yapısı tercih eder (indeks performansı). 3. OCSF evrim geçiriyor. v1.0.0 → v1.1.0 geçişinde breaking change oldu; ShamashAi kendi versiyonunu kontrol eder.
Ancak OCSF'nin core mapping logic'ini kullanıyoruz:
- OCSF
authentication.user.name→ ShamashAiuser - OCSF
network_activity.src→ ShamashAisrc_ip - OCSF
severity_id(1-6) → ShamashAiseverity(info/low/medium/high/critical) - OCSF
class_uid→ ShamashAievent_type
javascript // GET /ocsf/export (gelecek özellik) fastify.get('/ocsf/export', async (req, reply) => { const events = await db.query('SELECT * FROM dbo.events WHERE tenant_id = @tid', { tid: req.user.tenant_id }); const ocsfEvents = events.map(e => ({ class_uid: mapEventTypeToOCSF(e.event_type), severity_id: mapSeverityToOCSF(e.severity), time: new Date(e.timestamp).getTime(), activity_id: 1, metadata: { version: '1.1.0', product: 'ShamashAi' }, src_endpoint: { ip: e.src_ip }, dst_endpoint: { ip: e.dst_ip }, actor: { user: { name: e.user } }, message: e.message, })); return ocsfEvents; });
Şu an bu endpoint yok, ancak mimari hazır.
Compliance ve audit trail: kanonik şema üzerinde kanıt toplama
KVKK Madde 12 ve ISO 27001:2022 Annex A.8.15 "Logging" gereksinimi şunu der: "Kullanıcı etkinlikleri, istisnalar, hatalar ve güvenlik olayları kayıt altına alınmalı ve belirli süre saklanmalıdır." ShamashAi compliance raporu şu sorguyla kanıt toplar:
sql -- ISO 27001 A.8.15: son 90 günde yüksek riskli eventler SELECT event_type, severity, COUNT(*) AS total, MIN(timestamp) AS first_seen, MAX(timestamp) AS last_seen FROM dbo.events WHERE tenant_id = @tenantId AND severity IN ('high','critical') AND timestamp > DATEADD(DAY, -90, GETDATE()) GROUP BY event_type, severity ORDER BY total DESC;
Kanonik şema sayesinde bu sorgu tüm vendor'ları kapsıyor: Windows Event, Sophos, Fortinet, M365, AWS GuardDuty logları aynı tabloda, aynı formatta. Denetçiye sunulan rapor Excel export:
javascript // GET /compliance/evidence fastify.get('/compliance/evidence', async (req, reply) => { const rows = await db.query(/* yukarıdaki SQL */); const xlsx = generateExcel(rows, 'ISO27001_A815_Evidence'); reply.type('application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'); return xlsx; });
Bir başka kullanım: SOAR otomasyon audit. Her IP block, hesap kilitleme, quarantine işlemi dbo.soar_actions tablosuna event_type = SOAR_ACTION olarak yazılır:
sql INSERT INTO dbo.events (tenant_id, event_type, severity, timestamp, action, message, device_id) VALUES (@tid, 'SOAR_ACTION', 'info', GETDATE(), 'block_ip', 'SOAR: 192.168.1.50 Sophos firewall''da engellendi', @deviceId);
Denetçi "Otomasyonlar kim tarafından tetiklendi?" diye sorarsa:
sql SELECT timestamp, action, message, u.email FROM dbo.events e INNER JOIN dbo.audit_log a ON e.id = a.event_id INNER JOIN dbo.users u ON a.user_id = u.id WHERE e.tenant_id = @tid AND e.event_type = 'SOAR_ACTION' ORDER BY e.timestamp DESC;
Audit trail kanonik şema + JOIN ile otomatik oluşur.
Gerçek senaryo: Fortinet → Palo Alto migration sıfır alarm kaybı
Bir müşteri Fortinet firewall'u Palo Alto'ya değiştiriyor. Klasik SIEM'de:
1. 60+ korelasyon kuralı FortiGate CEF parser'a bağlı. 2. Dashboard 12 widget Fortinet alanlarını (srcintf, dstintf, policyid) sorguluyor. 3. Compliance raporu "Fortinet action=deny" filtresi kullanıyor.
Palo Alto devreye girdiğinde tüm bu mantık yeniden yazılmalı. 2-3 hafta sürer.
ShamashAi'da:
1. Yeni parser eklenir: parsers/paloalto.js → kanonik şema. 2. Cihaz device tablosunda vendor değiştirilir: UPDATE dbo.devices SET vendor='PaloAlto' WHERE id=8. 3. Hiçbir kural, dashboard, rapor değişmez. Çünkü hepsi event_type, severity, src_ip, dst_ip üzerinden çalışıyor.
Test ortamında geçiş süresi: 4 saat (parser yazımı 2 saat, test 2 saat). Canlıya alındığında sıfır alarm kaybı.
Limitler ve dürüst notlar
- 30 event_type yeterli mi? Pilot kapsamında ~80% kullanım senaryosunu kapsıyor. Eksik tipler (örneğin "DNS sinkhole", "privilege escalation via token manipulation") müşteri talebiyle eklenir; ShamashAi dokümantasyonunda henüz tam liste yok.
- Raw log kaybolur mu? Hayır,
raw_logsütunu her zaman dolu. Ancak 90 gün sonra (retention policy) raw log S3'e archive edilir, yalnızca kanonik alanlar hot-tier'da kalır. - Vendor-specific alanlar? Sophos "threat_id", Fortinet "attack_id" gibi özel alanlar şu an
messagestring içinde tutulur. Yapısal sorgu gerektiriyorsa JSON extension sütunu (gelecek özellik) planlanıyor. - OCSF tam uyumluluk yok. Export endpoint henüz yok; entegrasyon gerekiyorsa custom API yazılabilir.
- Parser hot-reload bazen 2-3 dakika gecikir. .NET agent'lar 60 saniyelik polling cycle kullanır; acil durumlarda manuel restart gerekebilir.