Pazartesi 06:47: Gece vardiyası nöbet defterinde sadece "SSH olayı kapandı" yazmış
Cumartesi 23:12'de event_type: BRUTE_FORCE_DETECTED tetiklemiş. Kaynak IP 185.220.x.x, hedef dc02.int.company.local. Gece vardiyasındaki IT operatörü olayı kapatmış ama nöbet defterinde yalnızca "SSH olayı incelendi, tehdit yok, kapandı" notunu bırakmış. Pazartesi sabahı gelen IT yöneticisi detaylara bakmak istiyor: fail2ban kuralı mı eklendi, ilgili IP güvenlik duvarına düştü mü, Active Directory audit log'u kaydedildi mi, ISO 27001 denetçisine kanıt paketi hazırlandı mı? Hiçbir yanıt yok. Aynı IP salı günü tekrar deneme yaparsa aynı prosedür tekrar mı işletilecek? Yoksa "geçen hafta da olmuştu, ne yaptık?" sorusuyla mı başlanacak?
Bu sahne Türkiye'deki orta ölçekli IT ekiplerinde her vardiya devrinde yaşanıyor. Yazılı prosedür yok, kişisel hafızaya güveniliyor, aynı olay tipi her geldiğinde farklı müdahale ediliyor. ShamashAi'nin Runbook Motoru, her event_type için standart yanıt prosedürünü sistemin içine gömüyor: adım adım talimat, kanıt yakalama kontrol listesi, onaylayan kişi, kapanış kriterleri. Vardiya devri artık "biz buna ne yapıyorduk?" sorusuyla başlamıyor; Incident Detail sayfasında ilgili runbook otomatik olarak açılıyor.
ShamashAi'de runbook anatomisi
ShamashAi'nin runbook motoru iki temel endpoint üzerinde çalışır:
GET /runbooks: Sistemdeki tüm runbook'ların listesini döner (event_type, başlık, son güncelleme tarihi).GET /runbooks/:id: Tek bir runbook'un tam Markdown içeriğini getirir.
1. Olay Tanımı: event_type ve tetikleme koşulu (ör. "5 dakikada 10+ başarısız SSH denemesi"). 2. İlk Müdahale Adımları: Sysadmin'in ilk 15 dakikada yapması gerekenler (kaynak IP'yi whois ile kontrol et, hedef sunucuda active session var mı bak, firewall log'una kaydet). 3. Kanıt Yakalama Kontrol Listesi: Hangi log dosyaları export edilmeli, hangi screenshot'lar alınmalı, hangi SQL sorguları çalıştırılmalı. 4. Onay Akışı: Hangi durumlarda IT müdürüne escalate edilmeli, hangi durumlarda olay doğrudan kapatılabilir. 5. Kapanış Kriterleri: Olayın "Resolved" statüsüne alınabilmesi için hangi şartlar sağlanmalı (ör. "Kaynak IP firewall'a eklendi VE incident_groups tablosunda ilişkili olay yok VE IT müdürü onayladı"). 6. İlgili SOAR Aksiyonlar: Bu olay tipi için hangi POST /soar/block veya POST /soar/quarantine endpoint'leri çağrılabilir.
ShamashAi pilot kurulumunda 30+ event_type için hazır runbook geliyor:
BRUTE_FORCE_DETECTEDAUTH_FAIL_USERM365_RISKY_SIGNINKNOWN_BAD_IPBEHAVIORAL_ANOMALYCERT_EXPIRINGSOAR_ACTION(SOAR motorunun kendisinin ürettiği olaylar için meta-runbook)BACKUP_FAILEDCRITICAL_SERVICE_DOWNPRIVILEGE_ESCALATIONUSB_DEVICE_INSERTEDFILE_INTEGRITY_VIOLATION- …ve 18+ ek olay tipi.
Incident Detail sayfasında otomatik runbook linki
ShamashAi web arayüzünde bir olayın detay sayfasını açtığınızda (örneğin /incidents/12345), sağ panelde "İlgili Runbook" bölümü otomatik olarak gösteriliyor. Sistem dbo.events tablosundaki event_type değerine bakıyor ve eşleşen runbook'u GET /runbooks/:id ile getirip Markdown render ediyor.
Örnek senaryo:
1. Cumartesi 03:22'de event_type: BACKUP_FAILED tetikledi. 2. IT operatörü /incidents/98321 sayfasını açtı. 3. Sağ panelde "BACKUP_FAILED Runbook" başlığıyla aşağıdaki adımlar gösteriliyor: - Adım 1: Backup sunucusunda (backup01.company.local) Veeam/Acronis log dosyasını kontrol et. - Adım 2: Disk doluluk durumunu df -h ile kontrol et (Linux) veya Get-PSDrive (Windows). - Adım 3: Son 7 günlük backup history'yi dbo.events tablosunda sorgula: sql SELECT event_time, event_type, source_host, details FROM dbo.events WHERE event_type = 'BACKUP_FAILED' AND event_time >= DATEADD(day, -7, GETDATE()) ORDER BY event_time DESC; - Adım 4: Eğer disk dolu değilse ve 3 günlük tekrar varsa, IT müdürüne escalate et. - Adım 5: Kanıt yakalama: Backup log dosyasını .txt olarak export et, disk kullanım screenshot'ını al, GET /reports/evidence-pack?incident_id=98321 endpoint'i ile otomatik PDF oluştur. - Kapanış: Backup başarılı çalıştığında ve Evidence Pack oluşturulduğunda olayı "Resolved" yap.
IT operatörü bu listeyi takip ediyor, her adımı işaretliyor. Vardiya devri sırasında bir sonraki operatör aynı sayfayı açtığında hangi adımların tamamlandığını görüyor (ShamashAi dokümantasyonu runbook adım durumunu takip etme özelliğinin backend detayını vermiyor; pilot kapsamında bu özellik aktif mi değil mi netleştirilir).
Custom runbook ekleme
ShamashAi 30+ hazır runbook ile geliyor ama her firma kendi özel prosedürlerini de eklemek isteyebilir. Örneğin firma içinde event_type: ERP_CONCURRENT_USER_LIMIT diye özel bir olay tipi tanımlamış olabilir (ERP lisansında aynı anda 50 kullanıcı sınırı var, aşıldığında uyarı). Bu olay tipi için ShamashAi'de hazır runbook yok.
Custom runbook ekleme süreci (ShamashAi dokümantasyonu UI üzerinden custom runbook ekleme akışını detaylandırmıyor; API veya SQL insert ile eklendiği varsayılıyor):
1. IT yöneticisi yeni bir runbook oluşturuyor: başlık "ERP Eşzamanlı Kullanıcı Limiti Aşıldı", event_type: ERP_CONCURRENT_USER_LIMIT. 2. Markdown editöründe prosedürü yazıyor: markdown ## İlk Müdahale - ERP sunucusunda (erp.company.local) aktif session sayısını kontrol et: sql SELECT COUNT(*) FROM erp_sessions WHERE logout_time IS NULL; - Eğer 50'den fazla session varsa, en eski 5 session'ı logoff et (kullanıcılara SMS gönder). - Lisans yöneticisine e-posta gönder: "Kullanıcı limiti aşıldı, ek lisans talebi değerlendirilsin".
## Kanıt Yakalama - ERP audit log'unu export et. - Active session listesini screenshot al. - GET /reports/evidence-pack?incident_id=XYZ ile PDF oluştur.
## Kapanış Kriterleri - Session sayısı 50'nin altına düştü VE lisans yöneticisi e-postası gönderildi. 3. Runbook kaydediliyor. Bundan sonra event_type: ERP_CONCURRENT_USER_LIMIT tetiklendiğinde Incident Detail sayfasında bu custom runbook otomatik olarak gösteriliyor.
ShamashAi dokümantasyonu custom runbook'ların version kontrolü, approval workflow, rollback gibi özelliklerini açıklamıyor; bu detaylar pilot programında netleşir.
Evidence pack içine runbook dahil etme
ShamashAi'nin GET /reports/evidence-pack?incident_id=12345 endpoint'i bir olaya ait tüm kanıtları (log export, screenshot, SQL sorgu sonuçları, timeline grafikleri) tek bir PDF'de topluyor. Runbook da bu PDF'in içine otomatik olarak ekleniyor.
Örnek senaryo:
event_type: M365_RISKY_SIGNINtetikledi (Türkiye'den login yapan kullanıcı 10 dakika sonra Rusya IP'sinden login yapmaya çalıştı).- IT operatörü runbook'u takip etti: kullanıcının parolasını resetledi, MFA'yı zorladı, Azure AD audit log'unu export etti.
GET /reports/evidence-pack?incident_id=45678çağrısı yaptı.- Oluşan PDF şu bölümleri içeriyor:
dbo.soar_actions tablosundan).
PDF denetçiye veya ISO 27001 audit'e sunulduğunda, "bu olaya nasıl müdahale ettiniz?" sorusuna runbook bölümü doğrudan yanıt veriyor. Müdahale prosedürü PDF'in içinde, elle yazılmış nöbet defteri notlarıyla değil.
.NET 8 agent ile runbook execution log'lama
ShamashAi'nin .NET 8 agent'ı (Windows sunucularda çalışan ShamashAgent.exe) belirli runbook adımlarını otomatik olarak işaretleyebiliyor (ShamashAi dokümantasyonu bu özelliğin tam kapsamını vermiyor; aşağıdaki örnek varsayıma dayalı).
Örneğin BRUTE_FORCE_DETECTED runbook'unda "Adım 3: Kaynak IP'yi Windows Firewall'a ekle" adımı varsa, agent şu Node.js Fastify endpoint'ini çağırıyor:
javascript // ShamashAi API (Node.js Fastify) fastify.post('/runbooks/:id/steps/:step_number/log', async (request, reply) => { const { id, step_number } = request.params; const { incident_id, executed_by, execution_result } = request.body;
await sql.query` INSERT INTO dbo.runbook_execution_log (runbook_id, step_number, incident_id, executed_by, execution_time, result) VALUES (${id}, ${step_number}, ${incident_id}, ${executed_by}, GETDATE(), ${execution_result}) `;
return { status: 'logged' }; });
Agent .NET 8 kodunda:
csharp // ShamashAi .NET 8 Agent using System.Net.Http.Json;
public async Task LogRunbookStep(string runbookId, int stepNumber, string incidentId, string result) { var payload = new { incident_id = incidentId, executed_by = Environment.MachineName, execution_result = result };
var response = await _httpClient.PostAsJsonAsync( $"https://shamashai.company.local/runbooks/{runbookId}/steps/{stepNumber}/log", payload );
response.EnsureSuccessStatusCode(); }
Bu sayede dbo.runbook_execution_log tablosunda hangi adımın ne zaman, hangi agent tarafından çalıştırıldığı kaydediliyor. Vardiya devri sırasında IT operatörü "Adım 3 tamamlandı mı?" diye sormak yerine execution log'una bakıyor.
Vardiya devri senaryosu: öncesi ve sonrası
Runbook motoru olmadan (öncesi):
- Cuma 18:00: Gündüz vardiyası bitiyor, akşam vardiyasına "bugün bir SSH olayı vardı, kapadım" diyor.
- Cumartesi 09:00: Gündüz vardiyası geldiğinde aynı IP tekrar deneme yapmış. "Geçen akşam ne yapıldı?" sorusu yanıtsız kalıyor. Firewall kuralı eklendi mi, Active Directory logları kaydedildi mi bilinmiyor.
- Pazartesi 10:00: IT müdürü ISO 27001 denetçisine "geçen hafta brute force olayına nasıl müdahale ettiniz?" sorusuna elle yazılmış nöbet defteri notu gösteriyor. Denetçi "prosedür standardizasyonu yok" notu düşüyor.
- Cuma 18:00:
BRUTE_FORCE_DETECTEDtetikledi. Gündüz vardiyası Incident Detail sayfasında runbook'u açtı, Adım 1-5'i tamamladı, her adımı işaretledi. - Cumartesi 09:00: Gündüz vardiyası aynı incident sayfasını açtığında hangi adımların tamamlandığını görüyor. Yeni deneme geldiğinde runbook'ta "Adım 6: Tekrar denemede IP'yi global blacklist'e ekle" yazıyor, operatör bunu uyguluyor.
- Pazartesi 10:00: IT müdürü
GET /reports/evidence-pack?incident_id=12345ile PDF oluşturuyor. PDF'in içinde runbook tam olarak render edilmiş, hangi adımların hangi saat aralığında tamamlandığıdbo.runbook_execution_logtablosundan çekilip timeline'a eklenmiş. Denetçiye standart prosedür kanıtı sunuluyor.
Behavior baselines ve runbook entegrasyonu
ShamashAi'nin dbo.behavior_baselines tablosu her cihaz/kullanıcı için normal davranış profilini tutuyor (ör. "ahmet@company.local kullanıcısı genelde 09:00-18:00 arası login yapar, haftada ortalama 120 e-posta gönderir"). event_type: BEHAVIORAL_ANOMALY tetiklendiğinde (ör. "ahmet 03:22'de login yaptı ve 500 e-posta gönderdi"), ilgili runbook şu adımları içeriyor:
1. Baseline karşılaştırması yap: sql SELECT avg_login_hour, avg_email_count FROM dbo.behavior_baselines WHERE user_principal_name = 'ahmet@company.local'; 2. Kullanıcıya SMS/e-posta gönder: "Hesabınızda olağandışı aktivite tespit edildi, siz misiniz?". 3. Eğer kullanıcı 15 dakika içinde onaylamazsa: Hesabı geçici olarak devre dışı bırak (POST /soar/quarantine). 4. Kanıt yakalama: Anomali raporunu PDF'e ekle, baseline grafiğini screenshot al. 5. Kapanış: Kullanıcı onayladı VE parolası resetlendi VE MFA aktif.
Bu runbook sayesinde IT operatörü "davranışsal anomali" dediğimizde ne yapacağını biliyor. Baseline tablosunu manuel sorgulamak yerine runbook SQL sorgusunu hazır veriyor.
Limitler ve dürüst notlar
- Runbook adım durumu takibi: ShamashAi dokümantasyonu her runbook adımının "tamamlandı/tamamlanmadı" durumunu UI'da checkbox ile işaretleme özelliğini açıklamıyor. Pilot kapsamında bu özelliğin aktif olup olmadığı netleştirilir.
- Approval workflow: Custom runbook'ların yayına alınmadan önce IT müdürü onayından geçmesi gerekiyor mu? Bu akış dokümante edilmemiş; pilot sırasında belirlenir.
- Runbook version kontrolü: Bir runbook güncellendiğinde eski incident'lerin hangi runbook versiyonunu göstereceği net değil. Git benzeri version history olup olmadığı pilot kapsamında paylaşılır.
- Çoklu dil desteği: Hazır 30+ runbook sadece Türkçe. Uluslararası şirketler için İngilizce runbook desteği şu an yok.
- Otomatik runbook execution: Runbook adımları şu an manuel takip ediliyor. Gelecekte "Adım 3: Firewall kuralı ekle" adımının SOAR motoruyla otomatik çalıştırılması planlanıyor ama henüz aktif değil.