ShamashAi Runbooks — Her Vaka Tipi İçin Yanıt Prosedürü

Vardiya devri sırasında kaybolmayan bilgi

Salı 22:37'de ShamashAi dashboard'unda yeni bir event belirir: BRUTE_FORCE_DETECTED — mail sunucusundan gelen 180 başarısız SMTP auth denemesi. Vardiyaya yeni geçmiş siber güvenlik analisti Mehmet ekrana bakar, event kartının üstünde kırmızı rozet yanıp söner. Mehmet iki ay önce işe başladı, ilk brute-force vakasını görmesi. Slack'te yazıyor: "Arkadaşlar bu SMTP brute-force'a ne yapıyoruz? Firewall'dan mı engelliyorduk, hesabı mı kapatıyorduk?" Üç dakika sonra kıdemli Ahmet cevap veriyor: "Geçen sefer mail sunucusunun IP'sini değiştirmiş gibiydik ama kesin hatırlamıyorum, yarın soruyorum." Ertesi sabah olay yayılmış, dört farklı servis hesabı kilitlenmiş, dış saldırgan bulunmuş değil.

Bu sahne 100-500 cihazdı orta ölçekli Türk firmalarında tekrar eder: yeni vaka geldiğinde "biz buna ne yapıyorduk?" sorusu, Slack geçmişi arama, vardiya devri kayıpları, her analistin farklı yöntem uygulaması. ShamashAi Runbooks modülü bu bilgi silosunu kaldırır. Her event_type için standart yanıt prosedürü tanımlanır, incident detail sayfasında otomatik bağlantı gösterilir, kanıt yakalama ve onaylayan rol listesi hazır durur. Vardiya devrinde IT operasyon biraz daha az kişiye bağlı olur.

ShamashAi Runbooks mimarisi

ShamashAi içinde dbo.runbooks tablosu her event_type için bir veya daha fazla runbook kaydı tutar. Tablo yapısı:

sql CREATE TABLE dbo.runbooks ( id INT IDENTITY PRIMARY KEY, event_type NVARCHAR(64) NOT NULL, title NVARCHAR(256) NOT NULL, body NVARCHAR(MAX) NOT NULL, -- Markdown format severity_filter NVARCHAR(16) NULL, -- critical, high, medium, low owner_role NVARCHAR(128) NULL, -- SOC Analyst, IT Manager, Network Admin approver_role NVARCHAR(128) NULL, checklist NVARCHAR(MAX) NULL, -- JSON array [{"task":"...","done":false}] created_at DATETIME2 DEFAULT GETDATE(), updated_at DATETIME2 DEFAULT GETDATE(), is_builtin BIT DEFAULT 0 ); CREATE INDEX ix_runbooks_event_type ON dbo.runbooks(event_type);

ShamashAi 30+ event_type için hazır runbook sağlar (is_builtin=1): BRUTE_FORCE_DETECTED, AUTH_FAIL_USER, M365_RISKY_SIGNIN, KNOWN_BAD_IP, BEHAVIORAL_ANOMALY, CERT_EXPIRING, SOAR_ACTION, BACKUP_FAILED ve diğerleri. Firmanız kendi event_type tanımladıysa (ör. CUSTOM_VPN_DISCONNECT) custom runbook ekleyebilirsiniz.

API endpoint'leri:

• GET /runbooks — tüm runbook listesi, event_type parametresiyle filtreleme
• GET /runbooks/:id — tekil runbook detayı
• POST /runbooks — yeni custom runbook oluştur (admin yetkisi gerekir)
• PUT /runbooks/:id — mevcut runbook güncelle
• DELETE /runbooks/:id — custom runbook sil (built-in silinemez)

Örnek GET /runbooks sorgusu:

javascript // Node.js + Fastify (ShamashAi API stack) fastify.get('/runbooks', async (request, reply) => { const { event_type, severity_filter } = request.query; let sql = 'SELECT * FROM dbo.runbooks WHERE 1=1'; const params = [];

if (event_type) { sql += ' AND event_type = @p0'; params.push({ name: 'p0', value: event_type }); } if (severity_filter) { sql += ' AND (severity_filter IS NULL OR severity_filter = @p1)'; params.push({ name: 'p1', value: severity_filter }); }

const pool = await mssql.connect(process.env.SQL_CONNECTION_STRING); const result = await pool.request() .input('p0', mssql.NVarChar, params[0]?.value) .input('p1', mssql.NVarChar, params[1]?.value) .query(sql);

return { runbooks: result.recordset }; });

Incident detail sayfasında otomatik runbook bağlantısı

ShamashAi web arayüzü (Next.js) incident kartını açtığınızda event_type değerine bakarak ilgili runbook'u sağ panelde gösterir. Örneğin BRUTE_FORCE_DETECTED event'i için:

typescript // Next.js (ShamashAi web stack) incident detail component import { useEffect, useState } from 'react';

interface Runbook { id: number; title: string; body: string; // Markdown owner_role: string; approver_role: string; checklist: Array<{ task: string; done: boolean }>; }

export function IncidentDetailPanel({ incident }: { incident: Incident }) { const [runbook, setRunbook] = useState<Runbook | null>(null);

useEffect(() => { fetch(/api/runbooks?event_type=${incident.event_type}) .then((res) => res.json()) .then((data) => { if (data.runbooks.length > 0) { setRunbook(data.runbooks[0]); } }); }, [incident.event_type]);

if (!runbook) return <div>Runbook bulunamadı</div>;

return ( <div className="runbook-panel"> <h3>{runbook.title}</h3> <div className="markdown-body"> {/* Markdown render edilir */} <ReactMarkdown>{runbook.body}</ReactMarkdown> </div> <div className="checklist"> <h4>Kontrol Listesi</h4> {runbook.checklist?.map((item, idx) => ( <label key={idx}> <input type="checkbox" checked={item.done} /> {item.task} </label> ))} </div> <p><strong>Sorumlu:</strong> {runbook.owner_role}</p> <p><strong>Onaylayan:</strong> {runbook.approver_role}</p> </div> ); }

Analist Mehmet artık BRUTE_FORCE_DETECTED vakasını açtığında sağ tarafta "SMTP Brute-Force Yanıt Prosedürü" başlıklı runbook görecek, adım adım şunlar yazıyor:

1. Kaynak IP tespit — dbo.events tablosunda source_ip sütununa bak, birden fazla IP varsa en çok deneme yapanı seç. 2. Firewall engelleme — POST /soar/block endpoint'ine {"ip": "...", "duration": 3600} gönder (1 saat geçici blok). 3. Kullanıcı hesap kontrolü — Hedef hesap kilitlendi mi? dbo.devices tablosunda last_auth_fail_count > 5 filtresiyle kontrol et. 4. Log yakalama — GET /reports/evidence-pack?incident_id=... ile kanıt paketi oluştur, mail sunucusu auth.log dosyalarını dahil et. 5. Onay — IT Manager'a Slack bildirim gönder, blok kararı onaylanırsa kalıcı firewall kuralı ekle. 6. Kapanış kontrol — 24 saat sonra aynı IP'den tekrar deneme oldu mu? dbo.events WHERE source_ip = '...' AND created_at > DATEADD(hour, -24, GETDATE())

Bu adımlar Markdown formatında dbo.runbooks.body alanında saklanır, ekip üyeleri web arayüzünde veya mobil uygulamada okur.

Kanıt yakalama ve Evidence Pack entegrasyonu

Runbook'lar sadece "ne yap" talimatı vermekle kalmaz, hangi kanıtları yakala bilgisini de içerir. ShamashAi GET /reports/evidence-pack endpoint'i incident kapatılırken otomatik çalışır, runbook içinde belirtilen kanıt tiplerini toplar:

• İlgili event raw log (JSON)
• Kaynak/hedef cihaz son 1 saat audit log
• SOAR action çıktısı (firewall blok komutu, quarantine sonucu)
• Runbook metninin kendisi (PDF veya Markdown)
• Onaylayan kullanıcının imza kaydı (dbo.audit_log tablosunda action='RUNBOOK_APPROVED')

Örnek evidence pack SQL sorgusu:

sql -- ShamashAi Evidence Pack builder (SQL Server) DECLARE @incident_id INT = 12345;

SELECT e.id AS event_id, e.event_type, e.source_ip, e.raw_log, r.title AS runbook_title, r.body AS runbook_body, sa.action_type AS soar_action, sa.result AS soar_result, al.user_email AS approver, al.created_at AS approval_time FROM dbo.events e INNER JOIN dbo.incident_groups ig ON e.incident_id = ig.id LEFT JOIN dbo.runbooks r ON e.event_type = r.event_type LEFT JOIN dbo.soar_actions sa ON e.id = sa.event_id LEFT JOIN dbo.audit_log al ON ig.id = al.incident_id AND al.action = 'RUNBOOK_APPROVED' WHERE ig.id = @incident_id;

Bu sorgu çıktısı JSON formatında paketlenir, KVKK Madde 12 uyarınca veri işleme faaliyeti kaydına eklenir, ISO 27001:2022 Annex A.5.28 (kanıt toplama) gereksinimini karşılar.

Custom runbook ekleme senaryosu

ShamashAi 30+ built-in runbook sağlıyor ama firmanıza özel event_type'larınız varsa kendi runbook'unuzu ekleyebilirsiniz. Örneğin finans departmanınız muhasebe yazılımında INVOICE_APPROVAL_TIMEOUT event'i tanımladı, bu event tetiklendiğinde muhasebe müdürüne SMS gönderilmesi, ardından manuel onay alınması gerekiyor.

POST /runbooks örneği:

javascript // Node.js + Fastify (ShamashAi API stack) fastify.post('/runbooks', async (request, reply) => { const { event_type, title, body, severity_filter, owner_role, approver_role, checklist } = request.body;

// Yetki kontrolü (admin role gerekir) if (request.user.role !== 'admin') { return reply.code(403).send({ error: 'Admin yetkisi gerekli' }); }

const pool = await mssql.connect(process.env.SQL_CONNECTION_STRING); const result = await pool.request() .input('event_type', mssql.NVarChar, event_type) .input('title', mssql.NVarChar, title) .input('body', mssql.NVarChar, body) .input('severity_filter', mssql.NVarChar, severity_filter) .input('owner_role', mssql.NVarChar, owner_role) .input('approver_role', mssql.NVarChar, approver_role) .input('checklist', mssql.NVarChar, JSON.stringify(checklist)) .query(` INSERT INTO dbo.runbooks (event_type, title, body, severity_filter, owner_role, approver_role, checklist, is_builtin) VALUES (@event_type, @title, @body, @severity_filter, @owner_role, @approver_role, @checklist, 0); SELECT SCOPE_IDENTITY() AS id; `);

return { id: result.recordset[0].id, message: 'Runbook oluşturuldu' }; });

Yeni runbook oluşturulduktan sonra INVOICE_APPROVAL_TIMEOUT event'i tetiklendiğinde ShamashAi incident detail sayfasında otomatik gösterilir.

Vardiya devri senaryosu: bilgi aktarımı kişiden bağımsız

Cuma akşam 18:00, SOC analisti Ahmet vardiyayı Zeynep'e devredecek. Geleneksel yöntemde Ahmet son 8 saatin olaylarını ağızdan anlatır: "Şu IP'yi engelledim, şu hesabı kapattım, şu sertifika yenilenecek." Zeynep not alır, ama cumartesi sabah 03:00'te yeni bir CERT_EXPIRING event'i geldiğinde Ahmet'in hangi adımları uyguladığını tam hatırlamaz.

ShamashAi Runbooks ile Zeynep incident kartını açar, "SSL Sertifika Yenileme Prosedürü" runbook'unu görür:

1. Sertifika bilgisi — dbo.devices tablosunda cert_expiry_date < DATEADD(day, 7, GETDATE()) filtresiyle yaklaşan son tarihli sertifikaları listele. 2. Yenileme isteği — IT Service Desk'e ticket aç, sertifika CN (Common Name) ve expiry tarihini ekle. 3. Onay bekleme — IT Manager onayladıktan sonra yeni sertifika dosyalarını /etc/ssl/certs/ dizinine yükle. 4. Test — openssl s_client -connect domain.com:443 komutuyla yeni sertifika geçerliliğini kontrol et. 5. Kapanış — dbo.audit_log tablosuna action='CERT_RENEWED' kaydı ekle.

Zeynep bu adımları izler, Ahmet'le iletişim kurmadan vakayı kapatır. Pazartesi sabah Ahmet işe geldiğinde dbo.audit_log tablosuna bakar, Zeynep'in hangi runbook adımlarını uyguladığını görür. Bilgi aktarımı kişiden bağımsız olmuştur.

SOAR entegrasyonu: runbook adımı otomasyona dönüşür

Bazı runbook adımları tekrar eden elle işlerdir: IP engelleme, hesap kilitleme, log arşivleme. ShamashAi SOAR modülü bu adımları otomatikleştirir. Runbook içinde [SOAR] etiketi varsa ilgili adım tetiklendiğinde SOAR workflow başlar.

Örnek BRUTE_FORCE_DETECTED runbook adımı:

markdown

Adım 2: Firewall Engelleme [SOAR]

Kaynak IP tespit edildikten sonra 1 saat geçici blok uygula.

SOAR Action: POST /soar/block Payload: {"ip": "{{source_ip}}", "duration": 3600, "reason": "Brute-force detected"}

ShamashAi bu [SOAR] etiketini gördüğünde dbo.soar_actions tablosuna yeni kayıt ekler, arka planda .NET 8 agent'i firewall API'sine istek gönderir:

csharp // .NET 8 (ShamashAi agent stack) SOAR action executor using System.Net.Http; using System.Text.Json;

public class SoarExecutor { private readonly HttpClient _httpClient;

public SoarExecutor(HttpClient httpClient) { _httpClient = httpClient; }

public async Task<string> BlockIpAsync(string ip, int duration, string reason) { var payload = new { ip, duration, reason };

var response = await _httpClient.PostAsJsonAsync("/soar/block", payload); response.EnsureSuccessStatusCode();

var result = await response.Content.ReadAsStringAsync(); return result; } }

SOAR action tamamlandığında dbo.soar_actions.result sütununa başarı/hata mesajı yazılır, runbook evidence pack'e dahil edilir.

Onaylayan rol ve kontrol listesi

Bazı runbook adımları hassas işlem içerir: kullanıcı hesabını kalıcı kilitleme, kritik sunucuyu yeniden başlatma, ağ segmentini izole etme. Bu adımlar analist yetkisiyle gerçekleştirilmemeli, IT Manager veya CISO onayı gerekir.

ShamashAi runbook'unda approver_role alanı bu kontrolü sağlar. Örneğin BEHAVIORAL_ANOMALY event'i için runbook:

{ "event_type": "BEHAVIORAL_ANOMALY", "title": "Kullanıcı Davranış Anomali Yanıtı", "owner_role": "SOC Analyst", "approver_role": "IT Manager", "checklist": [ {"task": "Kullanıcı son 7 gün aktivite raporu çıkar", "done": false}, {"task": "HR ile iletişime geç, kullanıcı ofiste mi?", "done": false}, {"task": "Hesabı geçici kilitle (1 saat)", "done": false}, {"task": "IT Manager onayı al", "done": false}, {"task": "Kalıcı kilit veya hesap sıfırlama uygula", "done": false} ] }

Analist Mehmet checklist'teki 3. adımı tamamladıktan sonra 4. adıma geçemez, sistem IT Manager rolündeki Ayşe'ye bildirim gönderir. Ayşe web arayüzünde "Onayla" butonuna basarsa dbo.audit_log tablosuna kayıt düşer, Mehmet 5. adıma geçebilir.

Limitler ve dürüst notlar

• Runbook versiyonlama yok: Şu anda bir runbook güncellendiğinde eski versiyon saklanmaz. Geçmişte hangi prosedürün uygulandığını görmek için dbo.audit_log tablosuna bakmak gerekir. İleriki sürümlerde version control eklenebilir.
• Markdown sınırlı render: Web arayüzü runbook içindeki Markdown'ı gösterir ama karmaşık tablo veya grafik desteklenmez. Basit liste, başlık, kod blokları çalışır.
• Built-in runbook düzenleme yapılamaz: 30+ hazır runbook is_builtin=1 işaretli, bunlar silinemez veya değiştirilemez. Kendi runbook'unuzu ekleyerek override edebilirsiniz.
• SOAR action sınırlı: Şu anda POST /soar/block, POST /soar/quarantine destekleniyor. Daha karmaşık workflow (ör. ticket aç, e-posta gönder, SMS) pilot kapsamında detay paylaşılır.
• Onay mekanizması senkron: IT Manager onayı beklerken incident kartı "pending approval" durumunda kalır. Birden fazla onaylayıcı veya eskalasyon kuralı henüz yok.

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