Merhaba! Bu ilk dersimizde, ileri düzey bir hata avcılığı (bug bounty) serüveninin temelini atacağız. Amacımız, karmaşık uygulamalar için standart veri akış diyagramlarının (Data Flow Diagrams - DFD) ötesine geçerek, özellikle gözden kaçan veri akışlarını ve ikincil işleme yollarını ortaya çıkaran gelişmiş DFD'ler oluşturmaktır. Bu beceri, tüm tehdit modelleme sürecimizin haritasını çıkaracağı ve bir sonraki adımlarda STRIDE metodolojisini uygulayacağımız zemini hazırlayacağı için kritik bir öneme sahiptir.
Güvenli mimari tasarımı ve tehdit modellemesi konusundaki tecrübeniz göz önüne alındığında, DFD'lerin temel amacını zaten biliyorsunuz. Bu derste biz, bir geliştiricinin veya sistem mimarının bakış açısından ziyade, bir saldırganın zihniyetiyle DFD oluşturmaya odaklanacağız. Amacımız sadece sistemin nasıl çalışması gerektiğini belgelemek değil, aynı zamanda beklenmedik, örtük ve az bilinen yollardan sömürülebilecek saldırı yüzeylerini keşfetmektir.
Bir Hata Avcısının Gözünden Veri Akış Diyagramları
Tehdit modellemesinin ilk adımı her zaman "Üzerinde çalıştığımız şey nedir?" sorusunu yanıtlamaktır. Bu sorunun en etkili yanıtı, iyi çizilmiş bir Veri Akış Diyagramı'dır. DFD, bir sistemdeki bileşenler, bu bileşenler arasındaki veri akışları ve verilerin depolandığı yerler hakkında görsel bir harita sunar.
Standart DFD elemanlarını ve amaçlarını hızlıca gözden geçirmek için NIST tarafından yayınlanan "Cybersecurity Threat Modeling" belgesindeki ilgili bölümleri inceleyerek başlayalım. Bu belge, DFD'lerin nasıl oluşturulduğuna ve 'Yüksek Değerli Veri Akışları' (High-Value Dataflows - HVDs) kavramına dair sağlam bir temel sunmaktadır.
[PDF] Cybersecurity Threat Modeling the Genomic Data Sequencing ...
Bu belgenin "Threat Modeling Example" bölümü, tehdit modellemenin dört temel sorusunu ve ilk adım olan sistemin belgelenmesini ele alıyor. DFD'lerin bu süreçteki rolünü anlamak için bu bölümü okumanızı öneririm.
Lütfen belgenin 11. sayfasındaki "Question 1: What are we working on?" başlığı altındaki ilk paragrafı ve ardından 12. sayfadaki "Table 2. Symbols Used in Detailed DFDs" başlıklı tabloyu dikkatlice inceleyin. Bu tablo, bir DFD'de kullanılan temel sembolleri (Dış Varlık, Süreç, Veri Deposu, Veri Akışı ve Güven Sınırı) açıklamaktadır.
Bir hata avcısı için DFD, sadece bir mimari şeması değil, bir hazine haritasıdır. Geliştiriciler genellikle uygulamanın birincil kullanım senaryolarına odaklanır: kullanıcının oturum açması, bir ürün satın alması, bir gönderi oluşturması vb. Ancak en yaratıcı ve yüksek etkili zafiyetler genellikle bu birincil yolların dışında, gözden kaçan "patikalarda" gizlidir.
Bu ikincil yolları ve kritik akışları belirlemek için NIST belgesinde de bahsedilen Yüksek Değerli Veri Akışları (High-Value Dataflows - HVDs) kavramını benimseyebiliriz. HVD'ler genellikle şu özelliklere sahiptir:
- Güven sınırlarını geçerler.
- Kritik bir işlevi yerine getirirler (örneğin, kimlik doğrulama, yazılım güncelleme).
- Kritik bir sisteme veya veriye erişirler.
Bir hata avcısı olarak görevimiz, bu HVD'leri ve özellikle belgelenmemiş veya "dahili" olarak kabul edilen diğer tüm akışları DFD'mize dahil etmektir.
Gelişmiş DFD Örnekleri
Modern uygulamalar nadiren monolitik bir yapıya sahiptir. Genellikle mikroservisler, üçüncü taraf API'ler, bulut hizmetleri ve karmaşık ağ topolojilerinden oluşurlar. Aşağıdaki DFD örnekleri bu karmaşıklığı göstermektedir.
Bu diyagramlar, basit bir "kullanıcı -> sunucu -> veritabanı" modelinin çok ötesinde düşünmemiz gerektiğini gösteriyor.
Gözden Kaçan Veri Akışlarını ve İkincil Yolları Keşfetmek
Gelişmiş bir DFD oluşturmanın anahtarı, birincil kullanıcı etkileşimlerinin ötesine bakmaktır. İşte bir hata avcısının DFD'sini zenginleştirmek için araması gereken bazı yaygın "gizli" veri akışı türleri:
1. Asenkron ve Arka Plan İşlemleri:
- Veri Akışı: Bir kullanıcı eylemi (örn. sipariş oluşturma), bir mesaj kuyruğuna (örn. RabbitMQ, Kafka) bir mesaj bırakır. Ayrı bir "worker" süreci bu mesajı alır ve işler (örn. e-posta gönderir, rapor oluşturur).
- Neden Önemli? Bu arka plan süreçleri, ana uygulamadan farklı yetkilere veya daha zayıf girdi doğrulamasına sahip olabilir. Birincil istekte zararsız görünen bir girdi, arka plan sürecinde işlendiğinde bir zafiyete (örn. ikinci dereceden SQL enjeksiyonu, SSTI) yol açabilir.
2. Operasyonel ve İdari Akışlar:
- Veri Akışı: Uygulama, olayları bir loglama servisine (örn. ELK Stack, Splunk) gönderir. Performans metrikleri bir izleme sistemine (örn. Prometheus, Zabbix) iletilir. Veritabanları düzenli olarak bir bulut depolama alanına yedeklenir.
- Neden Önemli? Log zehirlemesi (Log Poisoning) ile logları görüntüleyen yöneticilere yönelik XSS saldırıları yapılabilir. İzleme arayüzlerinde zafiyetler olabilir. Yedekleme süreçleri ve depolama alanları, yanlış yapılandırılmışsa hassas verilere erişim sağlayabilir. NIST belgesindeki yedekleme senaryosu (
HVD 5) bu duruma harika bir örnektir.
3. Üçüncü Taraf Entegrasyonları:
- Veri Akışı: Uygulama, ödemeler için Stripe'a, kimlik doğrulama için bir OAuth/SAML sağlayıcısına veya analiz için Google Analytics'e veri gönderir/alır. Webhook'lar aracılığıyla üçüncü taraf hizmetlerden veri alır.
- Neden Önemli? Bu akışlar, uygulamanızın en dış güven sınırlarında gerçekleşir. Protokollerin karmaşıklığı ve uygulama hataları (örn. yanlış yönlendirme URI'si doğrulaması, imza doğrulama eksikliği), hesap ele geçirme gibi kritik zafiyetlere yol açabilir.
4. Veri Senkronizasyon Akışları:
- Veri Akışı: Mikroservisler arasında veri tutarlılığını sağlamak için yapılan API çağrıları. Mobil uygulama ile web sunucusu arasında çevrimdışı verilerin senkronizasyonu.
- Neden Önemli? Bu "servisten servise" iletişim genellikle daha az denetlenir ve "dahili ağda olduğu için güvenli" varsayımıyla hareket edilebilir. Bu da yetkilendirme atlatma veya enjeksiyon zafiyetleri için bir kapı aralayabilir.
5. CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) Pipeline Akışları:
- Veri Akışı: Bir geliştirici kodu Git'e push'lar. Jenkins veya GitHub Actions tetiklenir, kodu derler, test eder ve sunucuya dağıtır.
- Neden Önemli? Yanlış yapılandırılmış bir CI/CD pipeline, kod deposundaki sırların (secrets) sızdırılmasına, kötü niyetli kodun üretim ortamına enjekte edilmesine veya derleme sunucularının ele geçirilmesine olanak tanıyabilir. Bu, giderek daha popüler hale gelen bir saldırı vektörüdür.
Bu ikincil akışları daha detaylı anlamak için NIST belgesindeki HVD örneklerini incelemek faydalı olacaktır. Bu örnekler, bir DFD'deki soyut bir çizgiden, adımları ve etkileşen tarafları olan somut bir sürece nasıl geçileceğini göstermektedir.
[PDF] Cybersecurity Threat Modeling the Genomic Data Sequencing ...
Bu belge, teorik DFD kavramlarını somut örneklerle hayata geçiriyor. Özellikle Yüksek Değerli Veri Akışlarının (HVD) nasıl daha derinlemesine analiz edildiğini gösteren kısımlar, bizim amacımız için çok değerli.
Lütfen 20. sayfadaki HVD'lere genel bakış bölümünü okuyun. Ardından, 21. sayfadan başlayarak HVD 1 ve HVD 2 örneklerini inceleyin. Bu örneklerin, bir veri akışını nasıl adım adım bir süreç diyagramına dönüştürdüğünü ve neden "yüksek değerli" olarak kabul edildiğini (güven sınırlarını geçme, kritik işlevler) gözlemleyin. Özellikle "Sequencer Remote Interface to Manufacturer" (HVD 2) örneği, bir üreticinin uzaktan bakım erişimi gibi genellikle göz ardı edilen bir ikincil yolu modellemektedir.
Düşünce Egzersizi: Karmaşık Bir Sistemi Modellemek
Şimdi, öğrendiklerimizi bir araya getirelim. Prabh Nair'in "Practical Threat Modeling" videosunda basit bir e-ticaret sitesi için DFD oluşturma süreci gösterilmektedir. Bu temel bir başlangıç noktasıdır.
Practical Threat Modeling Master Class: STRIDE-Powered
Bu video, STRIDE kullanarak pratik tehdit modellemesini anlatıyor. Özellikle, basit bir uygulama için DFD oluşturma adımlarını görsel olarak takip etmek faydalı olacaktır.
Lütfen videonun e-ticaret sitesi örneği bölümünü izleyin. Konuşmacının nasıl bileşenleri (React frontend, NodeJS backend, MySQL DB, Stripe) belirlediğini, güven sınırlarını çizdiğini ve temel veri akışlarını nasıl tanımladığını gözlemleyin. Bu, bizim şimdi üzerine inşa edeceğimiz temel yapıdır.
Şimdi bu temel e-ticaret sitesi örneğini, daha önce tartıştığımız ikincil yolları ekleyerek zenginleştirelim:
- Temel Bileşenler: React Frontend, NodeJS Sipariş Servisi, Java Kimlik Doğrulama Servisi, MySQL Kullanıcı Veritabanı, Redis Sepet Veritabanı.
- İkincil Yolları Ekleyelim:
- Sipariş onay e-postaları için bir RabbitMQ mesaj kuyruğu ve ayrı bir E-posta Servisi.
- Anlık sahtekarlık tespiti için sipariş verilerini işleyen bir Python (Flask) Analitik Servisi.
- Tüm servislerden log toplayan bir ELK Stack (Elasticsearch, Logstash, Kibana).
- Müşteri hizmetleri temsilcilerinin siparişleri görüntülemesi ve iade işlemlerini başlatması için bir dahili PHP Admin Paneli.
- Günlük yedeklemeleri alan ve bir AWS S3 bucket'ına yazan bir cron job.
Bu karmaşık sistemi DFD'ye dökerken kendinize şu soruları sorun:
- Sipariş Servisi'nden RabbitMQ'ya giden veri akışı nedir? Bu veri, E-posta Servisi tarafından nasıl tüketiliyor?
- Admin Paneli, Sipariş Servisi'nin veritabanına doğrudan mı erişiyor yoksa kendi API'si üzerinden mi? Bu panelin kimlik doğrulaması ana uygulamadan farklı mı?
- Tüm servisler loglarını Logstash'e nasıl gönderiyor? Bu log akışına enjekte edilen veri, Kibana'yı görüntüleyen bir yöneticinin tarayıcısında çalıştırılabilir mi?
- Yedekleme cron job'ı veritabanı kimlik bilgilerini nereden alıyor? S3 bucket'ının erişim izinleri nelerdir?
Bu sorular, DFD'nizi bir mimari belgesinden, hedeflenmiş saldırı hipotezleri geliştirmek için kullanabileceğiniz güçlü bir analitik araca dönüştürür.
Sonuç ve Sonraki Adımlar
Bu derste, bir hata avcısının tehdit modellemesindeki ilk ve en önemli adımı olan gelişmiş Veri Akış Diyagramları oluşturma üzerine odaklandık. Anahtar çıkarımlarımız şunlardır:
- Saldırgan Zihniyeti: DFD'ler, sadece sistemin nasıl çalıştığını değil, nasıl kırılabileceğini anlamak için oluşturulmalıdır.
- İkincil Yolları Keşfetmek: Asenkron işlemler, operasyonel araçlar (loglama, izleme), üçüncü taraf entegrasyonları ve CI/CD pipeline'ları gibi birincil kullanıcı akışlarının dışındaki yollar genellikle en zayıf halkalardır.
- Yüksek Değerli Veri Akışları (HVDs): Güven sınırlarını geçen, kritik verilere erişen veya önemli işlevleri yerine getiren veri akışlarını belirlemek ve önceliklendirmek, çabalarınızı odaklamanıza yardımcı olur.
Artık karmaşık bir sistemin veri akış haritasını nasıl çıkaracağımızı biliyoruz. Bir sonraki dersimizde, bu harita üzerindeki en kritik noktaları, yani güven sınırlarını (trust boundaries) derinlemesine analiz edeceğiz. Bir veri akışının bir güven sınırını geçtiği her nokta, potansiyel bir zafiyet barındırır ve STRIDE tehditlerini sistematik olarak uygulamak için mükemmel bir başlangıç noktasıdır.