Splunk’ı Claude’a Bağlamak

Yapay zekâ bir SIEM’in içine girdiğinde ne olur? Doğal dil ile indeks sorgulama, sourcetype keşfi ve canlı healthcheck, gerçek bir lab ortamından notlar. *

SOC’de yeterince yıl geçirdikten sonra fark edersiniz: asıl yorgunluk alarm sayısından değil, bağlam değiştirme maliyetinden gelir. Splunk’ta bir sorgu açarsınız, sonucu analiz edersiniz, başka bir sekmeye geçersiniz, tekrar dönersiniz. Bu döngü saatlerce sürer.

Bir gün şunu düşündüm: Splunk’a doğal dil ile konuşabilsem ne olurdu? “Son 24 saatte 4625 eventlerini getir, system kullanıcılarını dışla” diyebilsem? Cevap, Model Context Protocol (MCP) ile geldi.

Bu makale o serüveni anlatıyor, kurulumdan, canlı ortamdaki gerçek bulgulara kadar.

MCP (Model Context Protocol), büyük dil modellerini dış araçlara ve veri kaynaklarına bağlayan açık bir standarttır. Anthropic tarafından geliştirilmiştir.

Bunu şöyle düşünebilirsiniz: Claude bir danışman, MCP ise o danışmanın ofisinizdeki sistemlere erişim kartı. Danışmanınız artık sadece sizi dinlemiyor, kendi bilgisayarınızdaki veri tabanına da bakabiliyor.

SOC perspektifinden MCP’nin önemi şu: SIEM’iniz artık bir metin kutusuna dönüşüyor. SPL bilmeden soru sorabilirsiniz, ama SPL biliyorsanız çok daha hızlı hareket edebilirsiniz.

Test ortamım:

– 1 Search Head (Linux, Splunk 9.4.4)

– 3 Indexer — idx1, idx2, idx3 (cluster mode)

– 1 Heavy Forwarder — hf

– 1 Windows Client — ZZ-sanal (Universal Forwarder ile)

– 1 Ubuntu Client — UF kurulu

Adım 1: MCP Server Kurulumu

Splunkbase’den Splunk MCP Server uygulamasını indirip Splunk Enterprise’a yükleyin. Kurulumdan sonra Splunk’u yeniden başlatın. Bu entegrasyonda Splunk’un resmi MCP Server uygulaması (Splunkbase App #7931, v1.1.0 — https://splunkbase.splunk.com/app/7931) kullanılmıştır.

Adım 2: Rol ve Yetkilendirme

Rol adı tam olarak mcp_user olmalıdır. Splunk MCP Server bu ismi spesifik olarak arar; farklı isimde bir rol, doğru capability’lere sahip olsa bile çalışmaz.

Gerekli capability’ler: mcp_tool_execute (sorgu çalıştırma), mcp_tool_admin (tool yönetimi ve token oluşturma için).

Adım 3: Encrypted Token Oluşturma

Token’lar sadece MCP Server App içinden oluşturulmalıdır. Splunk’un standart Settings → Tokens sayfasından veya REST API ile oluşturulan token’lar sessizce reddedilir, hata mesajı vermez, sadece çalışmaz.

MCP Server App’i açın, “Create Token” butonuna tıklayın. Audience alanı otomatik olarak “mcp” gelir, değiştirilemez. Oluşturulan encrypted token sadece bir kez gösterilir, hemen kopyalayın.

Adım 4: Tool’ları Aktifleştirme

Kurulumdan sonra bazı MCP endpoint’leri varsayılan olarak kapalı gelir. Bağlantı sağlıklı görünür, handshake tamamlanır, splunk_get_info bile veri döner ama diğer tool’lar (SPL çalıştırma, AI Assistant vb.) client tarafında sessizce görünmez. Hata mesajı, uyarı yoktur.

MCP Server App → Settings ekranından ihtiyacınız olan tüm tool’ları açıkça etkinleştirin.

Adım 5: Claude Desktop Konfigürasyonu

claude_desktop_config.json dosyasına aşağıdaki konfigürasyonu ekleyin:

{

  “mcpServers”: {

    “splunk-mcp-server”: {

      “command”: “cmd”,

      “args”: [

        “/c”, “npx”, “-y”, “mcp-remote”,

        “https://<SPLUNK_HOST>:8089/services/mcp”,

        “–header”,

        “Authorization: Bearer <ENCRYPTED_TOKEN>”

      ],

      “env”: {

        “NODE_TLS_REJECT_UNAUTHORIZED”: “0”

      }

    }

  }

}

Windows’a özel önemli notlar:

Config dosyası konumu: Claude Desktop Microsoft Store’dan kuruluysa config dosyası standart %APPDATA%\Claude\ yolunda değildir. Store sandbox path’indedir: C:\Users\<kullanıcı>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\. En güvenilir yöntem, Claude Desktop içindeki Settings → Developer → Edit Config butonunu kullanmaktır.

npx path sorunu: Node.js, C:\Program Files\nodejs\ gibi boşluk içeren bir dizine kuruluysa “command”: “npx” başarısız olur. Çözüm: “command”: “cmd” ile args’ın başına “/c”, “npx” eklemektir.

PowerShell Execution Policy: npx çalıştırabilmek için Execution Policy’nin RemoteSigned olması gerekir: Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

Self-signed sertifika: Test/lab ortamında self-signed sertifika kullanılıyorsa NODE_TLS_REJECT_UNAUTHORIZED=0 env değişkeni gereklidir. Production’da mutlaka CA-signed sertifika kullanın.

Adım 6: Bağlantıyı Test Etme

Claude Desktop’u tamamen kapatıp yeniden açın (system tray’den sağ tık → Quit). Settings → Developer ekranında splunk-mcp-server bağlantısı görünmeli. Başarılı bağlantıda yeşil durum göstergesi, başarısızlıkta kırmızı “failed” etiketi görünür.

İlk test sorusu basit: “Bana tüm indeksleri sırala.”

Bağlantı kurulduktan sonra Claude’a yönelttiğim ilk soru şuydu:

“Bana bütün indeksleri sırala.”

Claude, arka planda şu sorguyu çalıştırdı:

| rest /services/server/info splunk_server=*

Ve geri dönen sonuç:

Ortamda 4 Splunk sunucusu (1 search head + 3 indexer) ve 20 unique indeks var.

İlk bulgular hemen dikkat çekiciydi. Güvenlik indeksleri; oswinsec, crowdstrike, winwef sistemde tanımlı ama içleri boş. Veri akışı hiç başlamamış ya da kesilmiş demekti.

Bir SOC analistinin en sık sorduğu soru: “Başarısız oturum açma denemeleri var mı?”

Claude’a şunu söyledim:

“Bana 4625’leri system kullanıcılarını dışlayacak şekilde son 24 saatteki hareketi getir.”

Claude otomatik olarak şu SPL’i oluşturup çalıştırdı:

index=oswinsec EventCode=4625

NOT (TargetUserName IN (“SYSTEM”, “LOCAL SERVICE”,

     “NETWORK SERVICE”, “ANONYMOUS LOGON”, “-“)

     OR TargetUserName=”*$”)

| timechart span=1h count AS failures

Sonuç: 0 kayıt.

Claude duraksayıp kendi kendine bir soruşturma başlattı. Sırasıyla şunları sorguladı:

— Hangi indekste WinEventLog var?

index=* sourcetype=WinEventLog | stats count by index

— Peki bu host son 30 günde ne gönderdi?

index=main sourcetype=WinEventLog | stats count by LogName

Ortaya çıkan tablo şaşırtıcıydı:

Security log geliyordu ama 4625 hiç yoktu. Ve son veri tarihi: 20 Nisan 2026. Yani 7 günlük bir veri boşluğu vardı.

Claude’un teşhisi:

“İki olası neden: (1) Audit Policy’de ‘Logon Failures’ auditing kapalı, (2) UF servisi 20 Nisan’dan beri çalışmıyor.”

Bu, bir analistin manuel olarak yapacağı araştırmayı Claude’un otomatik olarak gerçekleştirmesiydi. Araç çağrısı, bulgu, hipotez doğrulama döngüsü, her şey doğal dil konuşması içinde.

Bir sonraki adım daha ilginçti:

“Sourcetype’ları çıkart.”

Claude iki ayrı sorgu çalıştırdı hem genel indeksler hem de dahili (_*) indeksler için. Toplam 46 unique sourcetype döndü.

taopenctiaddon:log — 563K olay, ama yanlış indekste

OpenCTI add-on’u aktif ve veri üretiyor. Ancak veriler _internal indeksine düşüyor bu, konfigürasyon hatası. CTI telemetrisi main veya özel bir cti indeksine akmalı.

phantom_retry + phantom_configuration

Splunk SOAR (eski Phantom) entegrasyonu kurulu. phantom_retry’da 7.325 kayıt var — bu sayı başarısız playbook aksiyonlarını işaret edebilir. SOAR bağlantısının sağlığı sorgulanmalı.

linux_secure — 560K olay, ama indextest’te

560 bin Linux auth log’u bir test indeksinde yaşıyor. Bu kasıtlı mı, yoksa bir prod hatasının işareti mi?

skyhigh:dlp:audit

McAfee/Skyhigh DLP telemetrisi başlamış ama yalnızca 108 kayıt var. Yeni kurulum mu, yoksa veri akışı zayıf mı?

splunk:ta:o365:log

O365 TA kurulu ama log’ları _internal’e düşüyor. O365 verisi için indeks tanımı eksik.

En kapsamlı test buydu:

“Splunk’ta healthcheck yapar mısın?”

Claude sekiz farklı sorgu çalıştırarak ortamın tüm boyutlarını taradı.

Sunucu Durumu

Üç indexer’ın da yellow durumda olması kritik bir bulguydu.

Disk Kullanımı

Sıkıştırma oranı ~2.7:1 normal aralıkta.

CPU Kullanımı (Son 1 Saat)

Tüm sunucularda CPU %3’ün altında. Yük açısından sorun yok.

Error Log Analizi (Son 24 Saat)

Kritik Bulgular

1. Indexer’lar yellow — cluster replikasyon sorunu muhtemel. CMSlave hataları idx2 ve idx3’te görünüyor. Bucket replikasyon faktörü veya peer durumu bozulmuş olabilir. Splunk Web’deki Settings → Indexer Clustering ekranından doğrulanması gerekiyor.

2. SSL uyarıları — 613 adet, tek günde. SSLCommon + HttpListener kombinasyonu yüksek sayıda uyarı üretmiş. Süresi yaklaşan/dolmuş sertifika, eski TLS versiyonu veya cipher mismatch olabilir.

3. idx3 DiskMon — diğerlerinden belirgin şekilde yüksek. idx3’te disk I/O veya doluluk uyarıları diğer indexer’lardan çok daha fazla. Disk kapasitesi kritik eşiğe yaklaşıyor olabilir.

Keşif hızı. Bir ortama yeni geldiğinizde indeks yapısını, sourcetype dağılımını ve genel sağlık durumunu dakikalar içinde öğrenebilirsiniz.

Hipotez üretme. Claude sadece sorgu sonucu döndürmüyor; bulguları yorumluyor ve sonraki adımı öneriyor. “4625 yok” derken aynı zamanda “audit policy’yi kontrol et” diyor.

SPL öğrenme eğrisi. Analistler için mükemmel bir öğretmen. “Bu sonucu nasıl aldın?” diye sorulabilir, Claude SPL’i açıklar.

Healthcheck otomasyonu. Sekiz farklı sorguyu art arda çalıştırıp sonuçları bütünleşik bir rapor olarak sunmak manuel yapılsaydı 30-45 dakika sürerdi.

Gerçek zamanlı alarm değil. Claude’u bir detection engine olarak kullanmayın. Sorgular anında çalışır ama sürekli izleme için değil.

rest komutu kısıtlı. Bu entegrasyonda bazı Splunk REST API uç noktaları erişilebilir değildi. Cluster detayları için Splunk Web’e geçmek gerekti.

Hassas veri farkındalığı. Claude’a gönderdiğiniz her şey bir API çağrısına dönüşüyor. Kurumsal ortamlarda hangi verilerin paylaşıldığına dikkat edilmeli; özellikle kimlik bilgileri ve kişisel veri içeren log satırları.

Bu entegrasyon benim için bir araç değil, bir bakış açısı değişikliği oldu. SOC’de yıllardır “daha hızlı sorgu” peşinde koşuyorduk. Oysa asıl kazanım daha iyi soru sormak olabilir, hatta en iyi kazanım bu olur.

Claude, Splunk’u bir sorgu motoru olmaktan çıkarıp bir konuşma ortağına dönüştürüyor. “4625 var mı?” yerine “Bu ortamda kimlik doğrulama telemetrim neden eksik?” sorusunu soruyorsunuz ve cevap peşinden geliyor.

Aşağıdaki tablo, kurulum sırasında karşılaşılan sorunları ve çözümlerini içerir:

Kamil Akdağ

 - 7 Temmuz 2026, Salı