Giriş: Neden "Toplama" Değil "Mimari" Konuşuyoruz
OSINT (Open Source Intelligence) denince akla ilk gelen şey genelde bir liste olur: şu site, bu araç, şu Google dork'u, bu Telegram botu. Ama işin gerçeği şu — araç listesi OSINT değildir, OSINT'in hammaddesidir. Bir framework'ü diğerinden ayıran şey elindeki araç sayısı değil, o araçlardan gelen ham veriyi hangi mimari üzerinden işlediğindir.
Bu yazıda amacım "şu 50 aracı kullan" tarzı bir liste yazmak değil. Bunun yerine, ham dijital izin (bir kullanıcı adı, bir e-posta, bir IP, bir metadata parçası) nasıl bir boru hattından geçip "actionable intelligence" — yani üzerine karar inşa edilebilecek, doğrulanmış, bağlamlandırılmış bilgi — haline geldiğini, katman katman, mimari bir bakış açısıyla anlatacağım. Sonunda da bu alanın en tartışmalı kısımlarına — otomasyonun etik sınırları, "toplama vs. hedefleme" ayrımı, veri asimetrisi problemi — değineceğim.
1. Intelligence Cycle: OSINT'in Omurgası
Askeri ve istihbarat literatüründen gelen klasik "intelligence cycle" (istihbarat döngüsü), OSINT framework'lerinin de temelini oluşturur. Beş aşamalı bu döngü şöyle işler:
- Planning & Direction (Planlama) — Ne öğrenmek istiyorsun? Bu adım atlanınca insanlar saatlerce "veri toplar" ama elinde işe yarar hiçbir şey kalmaz.
- Collection (Toplama) — Ham veri elde etme aşaması. Web scraping, API sorguları, arşiv taraması, metadata çıkarımı.
- Processing (İşleme) — Ham veriyi normalize etme, tekilleştirme (deduplication), formatlama.
- Analysis (Analiz) — Verileri birbirine bağlama, çelişkileri tespit etme, güven skoru atama.
- Dissemination (Yayma) — Bulguyu, karar alacak kişinin/sistemin anlayacağı formatta sunma.
Çoğu amatör OSINT projesi 2. adımda takılı kalır. Asıl mühendislik problemi 3, 4 ve 5'tedir — çünkü toplama artık neredeyse çözülmüş bir problem. Asıl değer, o veriyi güvenilir bir sinyale dönüştürmekte.
2. Veri Katmanları: Kaynak Çeşitliliğinin Mimarisi
İyi bir OSINT framework'ü tek kaynağa güvenmez:
2.1 Statik Kaynaklar
WHOIS kayıtları, DNS geçmişi, sertifika transparency logları (crt.sh gibi), arşivlenmiş sayfalar (Wayback Machine).
2.2 Dinamik Kaynaklar
Sosyal medya API'leri, forum/haber akışları, canlı DNS sorguları. Gürültü oranı yüksektir.
2.3 Metadata Katmanı
Dosyalardan çıkarılan EXIF, yazar bilgisi, zaman damgaları — en çok göz ardı edilen ama en yüksek sinyal/gürültü oranına sahip katman.
2.4 İlişkisel Katman (Graph Layer)
Asıl "framework" burada devreye girer: e-posta → kullanıcı adı → GitHub commit'i → IP aralığı → ASN şeklinde zincirleme correlation, tek başına hiçbir katmanın veremeyeceği bağlamı üretir.
3. Correlation Engine: Asıl Mühendislik Problemi
Farklı kaynaklardan gelen entity'lerin aynı gerçek dünya nesnesine ait olup olmadığını belirlemek için üç yaklaşım var:
- Exact match: aynı e-posta, aynı hash. Yüksek güven, düşük kapsama.
- Fuzzy match: Levenshtein mesafesi, kullanıcı adı kalıpları. Orta güven, yüksek yanlış-pozitif riski.
- Davranışsal korelasyon: aktivite zaman damgası örtüşmesi. En ileri seviye ama en tartışmalı.
Her korelasyona bir güven skoru atanmalı. Güven skoru olmayan bir OSINT çıktısı istihbarat değil, iddia listesidir.
[Collection Layer]
↓ (rate-limited, scope-defined connectors)
[Normalization Layer]
↓ (schema'ya oturtma, tekilleştirme)
[Correlation Engine]
↓ (exact/fuzzy/behavioral matching + confidence scoring)
[Verification Layer]
↓ (çoklu kaynak doğrulama, çelişki tespiti)
[Presentation Layer]
↓ (graf görselleştirme, güven skoru ile raporlama)
4. Doğrulama Katmanı: Neden "Toplamak" Yetmez
En çok yapılan hata, toplanan veriyi doğrulama olmadan "bulgu" diye sunmaktır. Doğrulama katmanı şunları içermeli:
- Kaynak çeşitliliği kontrolü
- Zaman tutarlılığı
- Çelişki tespiti
Bu adım atlanınca ortaya "confirmation bias'ı otomatikleştirmiş bir sistem" çıkar.
5. Otomasyon vs. Ölçek: Nerede Durmalı?
Maksimalist görüş: "Açık kaynak, açık kaynaktır. Toplayıp ilişkilendirmek suç değildir."
Minimalist/etik-öncelikli görüş: "Mozaik teorisi" — tek başına zararsız 10 bilgi parçası, bir araya geldiğinde ciddi bir gizlilik ihlali olabilir.
Ben ikinci görüşe daha yakınım: bir sistemin teknik olarak yapabildiği ile yapması gereken şey aynı değildir. Scope'u kod seviyesinde kısıtlamak, niyete değil mimariye güvenmek demektir.
6. Veri Asimetrisi Problemi
OSINT araçlarının demokratikleşmesi bir yandan güzel bir güçlenme (gazeteciler, güvenlik uzmanları için), diğer yandan kötüye kullanım yüzeyini genişletiyor. Rate limiting, kapsam kısıtlamaları, log tutma zorunluluğu gibi tasarım kararları "usability vs. responsible design" gerilimini yönetmenin yollarıdır.
Kapanış: Araç Değil, Disiplin
OSINT'i güçlü kılan şey belirli bir scraper değil, disiplinli mimari yaklaşımdır. Bir framework'ün gerçek gücü, ne kadar çok veri topladığında değil, hangi veriyi toplamamayı seçtiğinde ortaya çıkar.
Bu yazı, OSINT metodolojisi ve framework tasarımı üzerine genel bir bakış sunmayı amaçlar; belirli bir hedefe yönelik operasyonel bir rehber değildir.
Kurguladığım framework’ün mimarisini ve çalışma mantığını optimize etmek birkaç günümü aldı. Yazının devamında, bu süreçte elde ettiğim teknik sonuçları paylaşıyorum
Top comments (0)