ShamashAi Category Health — firewall ne kadar log atmalı?

Cuma 14:40 — cihaz listesinde yalnızca iki firewall

Şirket ağında üç farklı lokasyonda beş Fortigate 100F cihazı var. ShamashAi web arayüzündeki Devices sayfasında yalnızca iki firewall görünüyor — üçü hiç event göndermiyor. Sysadmin bu firewall'ları manuel syslog ayarlamayı unutmuş olabilir; belki cihazların IP'si değişmiş, belki parser düzgün çalışmıyor. Daha sinsi senaryo: cihazlar event göndermiyor çünkü birisi yanlışlıkla logging'i kapattı. Klasik SIEM kurulumunda bu sessizliği fark etmek sistem yöneticisinin hafızasına ve disiplinine kalır. "Firewall'dan log gelmiyor mu?" sorusunu kimin aklına getirecek?

ShamashAi Category Health modülü bu tür "sessizlik"leri tespit etmek ve her cihaz kategorisi için normal log akış davranışını tanımlamak üzere tasarlandı. Firewall günde 50 event mi atmalı, yoksa 50K mı? Switch 3 saatlik heartbeat aralığı normal mi, yoksa 15 dakikada bir log gelmelimiş miydi? Database sunucusundan authentication log'u gelmiyor, bu beklenmedik bir durum mu? Identity Provider'dan credential metadata toplanıyor mu? Bu sorular cihaz tipi bazında yanıtlanmadıkça "coverage" metriği havada kalır.

Per-kategori profil mantığı

ShamashAi platform içinde cihazlar kategorilere atanır: firewall, switch, identity, server, database, nas, ap (wireless access point), endpoint, syslog, proxy gibi. Her kategori için ShamashAi category_health_profiles tablosunda bir sağlık profili tanımlar. Bu profil şu parametreleri içerir:

• expected_log_rate_min: günlük minimum event sayısı. Firewall için 1000, switch için 100, database için 50 gibi. Cihaz bu eşiğin altında kalırsa "sessiz" olarak işaretlenir.
• expected_log_rate_max: günlük maksimum beklenen event sayısı. Aşırı yüksek trafik (örneğin 1 milyon event/gün) parser veya loop sorununa işaret edebilir.
• heartbeat_interval_minutes: cihazdan beklenen maksimum sessizlik süresi. Firewall için 15 dakika, network switch için 60 dakika, endpoint agent için 5 dakika gibi. Eğer bu süre aşılırsa cihaz "stale" olarak işaretlenir.
• credential_required: true ise cihaz için credential (kullanıcı adı/parola veya API token) girilmiş olması beklenir. Identity Provider (Active Directory, Entra ID) ve bazı database'ler için zorunlu.
• parser_quality_threshold: 0.0 - 1.0 arası değer. Gelen raw log'ların yüzde kaçının başarıyla parse edildiğini ölçer. Firewall için 0.85 (yüzde 85 başarı), switch için 0.75 gibi. Parser kalitesi bu eşiğin altındaysa "parser sorunlu" bulgusu oluşur.
• min_event_types: cihazdan beklenen farklı event_type sayısı. Firewall'dan yalnızca CONN_ESTABLISHED event'i geliyorsa, AUTH_FAIL, FW_BLOCK, POLICY_VIOLATION gibi event tipleri eksiktir. Bu durum firewall log policy'sinin dar olduğuna işaret eder.

Bu profiller fabrika ayarı olarak ShamashAi içinde gelir, ancak IT Manager roadmap'te bu değerleri admin panelinden özelleştirebilecek. Örneğin 50 kullanıcılı bir KOBİ'nin firewall'ı günde 500 event yeterli sayabilir, 500 kullanıcılı firma ise 10K beklenti koyabilir.

category_health_profiles tablosu ve SQL sorgu

ShamashAi backend dbo.category_health_profiles tablosunda kategori başına bu kuralları tutar. Örnek tablo şeması:

sql CREATE TABLE dbo.category_health_profiles ( category NVARCHAR(50) PRIMARY KEY, expected_log_rate_min INT, expected_log_rate_max INT, heartbeat_interval_minutes INT, credential_required BIT, parser_quality_threshold DECIMAL(3,2), min_event_types INT, updated_at DATETIME2 DEFAULT GETDATE() );

INSERT INTO dbo.category_health_profiles VALUES ('firewall', 1000, 500000, 15, 0, 0.85, 5, GETDATE()), ('switch', 100, 100000, 60, 0, 0.75, 3, GETDATE()), ('identity', 200, 200000, 30, 1, 0.90, 4, GETDATE()), ('database', 50, 50000, 60, 1, 0.80, 3, GETDATE()), ('nas', 10, 10000, 120, 0, 0.70, 2, GETDATE()), ('ap', 50, 50000, 60, 0, 0.70, 3, GETDATE());

IT yöneticisi bu tabloyu sorgulayarak hangi kategoriye hangi beklentilerin uygulandığını görebilir. Roadmap'te bu profilleri web panelinden düzenleme özelliği gelecek; şimdilik SQL üzerinden manuel update mümkün (destek ekibi eşliğinde).

/category-health/findings endpoint — kural ihlalleri

ShamashAi backend her 15 dakikada bir dbo.devices ve dbo.events tablolarını tarayarak her cihazın sağlık durumunu kontrol eder. Profildeki kuralları ihlal eden cihazlar dbo.category_health_findings tablosuna yazılır. Web API bu bulguları /category-health/findings endpoint'inden sunar:

javascript // Node.js Fastify route örneği (ShamashAi backend) fastify.get('/category-health/findings', async (request, reply) => { const { category, finding_type } = request.query; const sql = ` SELECT f.device_id, d.hostname, d.category, f.finding_type, f.severity, f.details, f.detected_at FROM dbo.category_health_findings f JOIN dbo.devices d ON f.device_id = d.device_id WHERE (@category IS NULL OR d.category = @category) AND (@finding_type IS NULL OR f.finding_type = @finding_type) AND f.resolved = 0 ORDER BY f.severity DESC, f.detected_at DESC; `; const result = await request.server.mssql.query(sql, { category: category || null, finding_type: finding_type || null }); return { findings: result.recordset }; });

finding_type değerleri:

• SILENT_DEVICE: expected_log_rate_min eşiğinin altında log.
• LOG_FLOOD: expected_log_rate_max eşiğinin üzerinde log.
• HEARTBEAT_EXPIRED: heartbeat_interval_minutes süresi aşıldı.
• CREDENTIAL_MISSING: credential_required=1 ama cihaz credential bilgisi yok.
• PARSER_QUALITY_LOW: parse başarı oranı parser_quality_threshold altında.
• EVENT_TYPE_DIVERSITY_LOW: min_event_types sayısının altında farklı event tipi.

Örneğin firewall kategorisinde SILENT_DEVICE bulgusu varsa, sysadmin o cihazın syslog ayarını ve firewall policy'sini kontrol edebilir.

Coverage sayfası — tek bakışta sağlık özeti

ShamashAi web arayüzündeki Coverage sayfası kategori bazında toplam cihaz sayısı, aktif cihaz sayısı, sessiz cihaz sayısı ve parser kalitesi ortalamalarını gösterir. Sayfanın üst kısmında kategori kartları (firewall, switch, identity, database...) yer alır; her kart üzerinde:

• Toplam cihaz sayısı
• Son 24 saatte log gönderen cihaz sayısı
• SILENT_DEVICE bulgusu olan cihaz sayısı (kırmızı badge)
• PARSER_QUALITY_LOW bulgusu olan cihaz sayısı (sarı badge)
• CREDENTIAL_MISSING bulgusu olan cihaz sayısı (turuncu badge)

Örneğin "Firewall" kartı:

Firewall (5 cihaz) ✅ Aktif: 3 🔴 Sessiz: 2 🟡 Parser sorunu: 1

Kullanıcı karta tıkladığında o kategoriye ait tüm cihazların listesi, her birinin son event zamanı, günlük log sayısı ve parser başarı oranı detayıyla açılır. Liste doğrudan /category-health/findings?category=firewall API sorgusuyla beslenir.

Visibility Gaps sayfası — priority sıralaması

Coverage sayfası genel özet sunarken, Visibility Gaps sayfası bulguları priority sırasına koyar. ShamashAi her bulguya bir öncelik puanı atar:

• CREDENTIAL_MISSING + category=identity → Critical (identity olmadan kullanıcı davranışı izlenemez)
• SILENT_DEVICE + category=firewall → High (firewall trafiği SOC'un ana veri kaynağı)
• PARSER_QUALITY_LOW + category=database → Medium (database log'u parse edilemezse compliance kanıtı eksik)
• HEARTBEAT_EXPIRED + category=ap → Low (access point sessizliği ağ kesintisi olabilir, ama SIEM açısından ikincil)

Visibility Gaps sayfası bu bulguları priority'ye göre listeler ve her biri için önerilen aksiyon sunar:

markdown

Critical

• dc01.local (Identity): Credential eksik. Active Directory entegrasyonu için shamashai-agent.exe kurulumu gerekli.

High

• fw-ankara.local (Firewall): Son 24 saatte yalnızca 120 event. Syslog policy genişletilmeli (deny, accept, auth-fail log'ları aktif mi?).
• fw-izmir.local (Firewall): 48 saattir log yok. Syslog server IP'si doğru mu? ShamashAi collector erişilebilir mi?

Medium

• sql01.local (Database): Parser başarı oranı %62. SQL Server audit log formatı ShamashAi parser'a uygun değil; destek ekibine ticket açın.

Bu sayfa IT Manager'ın günlük rutin kontrolünde ilk bakacağı ekrandır. Her sabah Visibility Gaps sayfasını açarak hangi cihazın sessiz kaldığını, hangi kategoride credential eksik olduğunu kontrol eder.

Örnek senaryo: firewall sessizliği tespiti

Ankara ofisinde bir Fortigate 200E var. Cuma günü yanlışlıkla log policy değişikliği yapılıyor ve yalnızca "accept" action'ları loglanıyor, "deny" ve "auth-fail" logları kapatılıyor. Cumartesi sabahı IT Manager Coverage sayfasını açtığında şunu görür:

Firewall (3 cihaz) ✅ Aktif: 2 🔴 Sessiz: 1 (fw-ankara)

fw-ankara detayına tıkladığında:

• Son 24 saatte 150 event (beklenen: 1000+)
• Event tipi çeşitliliği: 1 (yalnızca CONN_ESTABLISHED; FW_BLOCK, AUTH_FAIL_USER eksik)
• Finding type: SILENT_DEVICE, EVENT_TYPE_DIVERSITY_LOW

IT Manager hemen firewall policy'sine bakar, deny ve auth-fail log'larının kapalı olduğunu görür, düzeltir. 15 dakika sonra ShamashAi yeniden kontrol eder, fw-ankara günlük 8K event göndermeye başlar, bulgu "resolved" olarak işaretlenir.

Bu senaryoda Category Health modülü olmasa IT Manager sessizliği ancak bir güvenlik olayı araştırırken "firewall log'u neden yok?" diye fark edecekti — muhtemelen günler sonra.

Parser kalitesi izleme

Parser kalitesi dbo.events tablosundaki parsed ve parse_error alanlarından hesaplanır. ShamashAi her event'i aldığında onu parse etmeye çalışır; başarılıysa parsed=1, başarısızsa parsed=0 ve parse_error alanına hata mesajı yazar. Her cihaz için günlük parser başarı oranı:

sql SELECT device_id, COUNT(*) AS total_events, SUM(CASE WHEN parsed = 1 THEN 1 ELSE 0 END) AS parsed_count, CAST(SUM(CASE WHEN parsed = 1 THEN 1 ELSE 0 END) AS FLOAT) / COUNT(*) AS parse_rate FROM dbo.events WHERE received_at >= DATEADD(day, -1, GETDATE()) GROUP BY device_id;

Eğer bir firewall'ın parse_rate değeri 0.85'in (yüzde 85) altındaysa, PARSER_QUALITY_LOW bulgusu oluşur. Bu durum genellikle:

• Firewall firmware güncellemesi sonrası log formatı değişmiş.
• ShamashAi parser henüz o cihaz modelini tam desteklemiyor.
• Syslog üzerinden gelen log truncate olmuş (maksimum satır uzunluğu aşımı).

IT Manager bu bulguyu görünce destek ekibine örnek raw log gönderir, parser güncellenir. Roadmap'te parser otomatik learning özelliği var (AI destekli), ancak şimdilik manuel destek gerekli.

Credential varlık kontrolü

Identity kategorisi (Active Directory, Entra ID) ve bazı database'ler için credential_required=1 kuralı var. ShamashAi bu cihazlardan log toplayabilir, ama credential olmadan enrichment yapamaz. Örneğin Active Directory credential'ı yoksa:

• AUTH_FAIL_USER event'indeki kullanıcı adı yalnızca string olarak kalır; kullanıcının departmanı, grup üyelikleri, manager bilgisi enrich edilemez.
• M365_RISKY_SIGNIN event'inde user_id varsa ama AD'den detay çekilemezse, SOAR aksiyonu (hesap disable) çalıştırılamaz.

Coverage sayfası identity kategorisinde CREDENTIAL_MISSING bulgusu gösteriyorsa, IT Manager Integrations sayfasından Active Directory entegrasyonunu tamamlamalıdır. ShamashAi .NET 8 agent (shamashai-agent.exe) domain controller'a kurulur veya LDAPS credential girilir.

Heartbeat ve stale cihaz mantığı

heartbeat_interval_minutes değeri her kategori için farklıdır. Endpoint agent 5 dakikada bir "heartbeat" event'i gönderir (event_type=HEARTBEAT); eğer 5 dakika geçmesine rağmen event gelmezse endpoint "stale" olur. Network switch ise saatler boyunca sessiz kalabilir (örneğin hiç trafik yoksa), bu yüzden heartbeat süresi 60 dakikadır.

ShamashAi backend şu SQL sorgusuyla stale cihazları tespit eder:

sql SELECT d.device_id, d.hostname, d.category, p.heartbeat_interval_minutes, MAX(e.received_at) AS last_event, DATEDIFF(MINUTE, MAX(e.received_at), GETDATE()) AS minutes_since_last_event FROM dbo.devices d JOIN dbo.category_health_profiles p ON d.category = p.category LEFT JOIN dbo.events e ON d.device_id = e.device_id GROUP BY d.device_id, d.hostname, d.category, p.heartbeat_interval_minutes HAVING DATEDIFF(MINUTE, MAX(e.received_at), GETDATE()) > p.heartbeat_interval_minutes;

Bu sorgu sonucu dbo.category_health_findings tablosuna HEARTBEAT_EXPIRED bulgusu eklenir. IT Manager Visibility Gaps sayfasından bu cihazları görür.

Roadmap: profil özelleştirme ve otomatik iyileştirme

Mevcut sürümde category_health_profiles fabrika ayarıdır. Roadmap'te IT Manager bu profilleri admin panelinden düzenleyebilecek:

• "Firewall kategorisi için benim firmamda günlük 500 event yeterli" ayarı.
• "Switch'lerden 2 saatte bir log bekliyorum" gibi özel heartbeat.
• Kategori başına parser threshold farklılaştırma.

Ayrıca AI destekli otomatik profil önerisi de roadmap'te: ShamashAi 30 gün boyunca her cihazın davranışını öğrenir, ardından "Bu firewall ortalama 12K event/gün gönderiyor, profil 1K'dan 10K'ya çıkartılmalı" önerisi sunar. IT Manager bu öneriyi onaylar veya reddeder.

Şu an bu özellik yoktur; özelleştirme ihtiyacı varsa pilot kapsamında AfnTeknoloji destek ekibiyle birlikte SQL güncellemesi yapılır.

.NET 8 agent ve heartbeat event

ShamashAi .NET 8 agent (Windows sunucu ve endpoint'lere kurulan shamashai-agent.exe) her 5 dakikada bir şu event'i gönderir:

csharp // C# .NET 8 agent snippet (ShamashAi agent) using System.Net.Http.Json; using System.Timers;

var heartbeatTimer = new Timer(300000); // 5 dakika = 300000 ms heartbeatTimer.Elapsed += async (sender, e) => { var heartbeatEvent = new { event_type = "HEARTBEAT", device_id = DeviceConfig.DeviceId, hostname = Environment.MachineName, timestamp = DateTime.UtcNow, agent_version = "2.1.0", cpu_percent = GetCpuUsage(), memory_percent = GetMemoryUsage() }; await httpClient.PostAsJsonAsync("https://shamash-collector/events/ingest", heartbeatEvent); }; heartbeatTimer.Start();

Bu heartbeat event'i sayesinde ShamashAi endpoint'in erişilebilir ve agent'ın çalıştığını bilir. Eğer 5 dakika içinde heartbeat gelmezse endpoint HEARTBEAT_EXPIRED bulgusu alır. IT Manager Coverage sayfasında endpoint kategorisinde sessiz cihazları görür, agent servisini kontrol eder.

SQL Server audit log ve parser kalitesi

Bir müşteri senaryosu: SQL Server audit log formatı karmaşık ve her SQL sürümünde (2017, 2019, 2022) hafif değişiklik var. ShamashAi parser SQL 2019 formatını yüzde 90 başarıyla parse ediyor, ancak SQL 2017'nin bazı audit event'lerinde action_id alanı farklı — parser bu satırları parse_error ile işaretliyor. Günlük 1000 event'in 200'ü parse edilemiyor, parser kalitesi yüzde 80. category_health_profiles tablosunda database kategorisi parser_quality_threshold=0.80 olduğu için bulgu oluşmuyor. Ama IT Manager eşiği 0.85'e çıkartırsa, sistem PARSER_QUALITY_LOW bulgusu verir. Bu durumda destek ekibi SQL 2017 audit log örneği ister, parser'ı günceller.

ShamashAi dokümantasyonu parser detaylarını tam açıklamıyor; pilot kapsamında log örnekleri paylaşılarak parser iyileştirmesi yapılır.

Next.js web arayüzü ve Coverage kartları

ShamashAi Next.js web arayüzünde Coverage sayfası şu şekilde render edilir:

javascript // Next.js component (ShamashAi web) import { useEffect, useState } from 'react';

export default function CoveragePage() { const [categories, setCategories] = useState([]);

useEffect(() => { fetch('/api/category-health/summary') .then(res => res.json()) .then(data => setCategories(data.categories)); }, []);

return ( <div className="grid grid-cols-3 gap-4"> {categories.map(cat => ( <div key={cat.category} className="card border p-4"> <h3 className="font-bold">{cat.category}</h3> <p>Toplam: {cat.total_devices}</p> <p className="text-green-600">✅ Aktif: {cat.active_devices}</p> {cat.silent_count > 0 && ( <p className="text-red-600">🔴 Sessiz: {cat.silent_count}</p> )} {cat.parser_issues > 0 && ( <p className="text-yellow-600">🟡 Parser sorunu: {cat.parser_issues}</p> )} {cat.credential_missing > 0 && ( <p className="text-orange-600">🟠 Credential eksik: {cat.credential_missing}</p> )} </div> ))} </div> ); }

Backend /api/category-health/summary endpoint'i dbo.devices ve dbo.category_health_findings tablolarını join ederek kategori bazında özet döner.

Limitler ve dürüst notlar

• Profil özelleştirme web arayüzünden yapılamıyor. Fabrika ayarları kullanılıyor; özel ihtiyaç varsa SQL update veya destek talebi gerekli. Roadmap'te admin paneli var.
• Parser otomatik öğrenme yok. Yeni cihaz modeli veya firmware güncellemesi sonrası parser manuel güncellenir. AI destekli parser learning roadmap'te.
• Kategori tanımları sabit. Kullanıcı yeni kategori ekleyemiyor (örneğin "ICS", "OT"). Mevcut kategoriler: firewall, switch, identity, server, database, nas, ap, endpoint, proxy, syslog.
• Heartbeat event'i agent dışındaki cihazlardan gelmez. Network cihazları (firewall, switch) heartbeat göndermez; yalnızca normal log akışı izlenir. Endpoint'ler için .NET agent heartbeat gönderir.
• Parser kalitesi hesabı anlık değil, günlük toplu. Her event parse edildiğinde anında skor güncellenmez; backend 15 dakikada bir toplu hesap yapar. Gerçek zamanlı parser skoru roadmap'te.

Pilot programı 30 gün ücretsiz: shamashai.com.tr/iletisim