TS 13638 Standardında Web Uygulama Güvenlik Testleri

Neden bir standart gerekti?

Türkiye’de sızma testi hizmeti uzun süre bireysel yetkinliğe dayalı yürütüldü. Firmalar kendi yöntemlerini belirledi, raporlarını kendi formatında hazırladı. Bu durum, testin kalitesini kurumdan kuruma farklılaştırdı.

Kamu kurumları ve finans sektörü için bu belirsizlik ciddi bir risk taşıyordu. Nitekim, bir bankanın güvenlik seviyesini ölçen test, başka bir kurumun testinden çok farklı bir derinlikte olabiliyordu. Dolayısıyla ortak bir ölçüt ihtiyacı doğdu.

TSE, bu ihtiyaca karşılık TS 13638 standardını yayımladı. Böylelikle, standart, sızma testi yapan firma ve personel için asgari şartları belirliyor. BDDK, EPDK, SPK ve TCMB gibi düzenleyici kurumlar da bu standardı referans alıyor. Denetimli sektörlerdeki kurumlar, testlerini TSE belgeli firmalara yaptırmayı tercih ediyor. Bu tercih hem yasal uyumu kolaylaştırıyor hem de test sonuçlarının güvenilirliğini artırıyor.

TS 13638 ne anlatır?

Standardın tam adı “Bilgi Teknolojileri – Güvenlik Teknikleri – Sızma Testi Yapan Personel ve Firmalar İçin Şartlar.” Yani standart, doğrudan bir teknik test kılavuzu değil; kim test yapabilir, hangi yetkinlikte olmalı, süreç nasıl işlemeli sorularına cevap veriyor.

Personel de kendi içinde bir hiyerarşiye sahip. Özellikle, kıdemli uzman, uzman ve sertifikalı uzman gibi kademeler, tecrübe ve sınav geçmişine göre ayrılıyor. Bir A sınıfı firmanın ekibinde bu kademelerin belirli bir oranda temsil edilmesi bekleniyor.

Aynı zamanda, standart, test sürecini üç ana aşamaya ayırıyor: planlama, uygulama ve raporlama. Her aşamanın kendi belgeleme ve izlenebilirlik şartı bulunuyor. Personel tarafında uluslararası sertifikalar da önemli bir rol oynuyor. OSCP, GPEN, LPT gibi belgeler, TSE’nin sınav muafiyeti tanıdığı sertifikalar arasında yer alıyor.

Diğer standartlarla ilişkisi

TS 13638, tek başına bir ada gibi durmuyor. ISO/IEC 27001 bilgi güvenliği yönetim sistemiyle doğrudan bağlantılı. Bir kurumun ISO 27001 belgesi varsa, düzenli sızma testi zaten bu sistemin bir gereği olarak karşımıza çıkıyor.

KVKK tarafında da benzer bir ilişki var. Kanunun on ikinci maddesi, veri sorumlusuna teknik tedbir alma yükümlülüğü getiriyor. Sızma testi raporu, bu yükümlülüğün yerine getirildiğine dair somut bir kanıt oluşturuyor. Ödeme sistemleriyle çalışan kurumlar için PCI-DSS de devreye giriyor. Sonuç olarak, bu standart, kart verisi işleyen sistemler için düzenli test şartı koyuyor.

Web uygulamalarında kapsam

Web uygulaması testleri, standardın en çok işletilen alanlarından biri. Ancak kapsam, sadece bilinen açıkları taramaktan ibaret değil. Uzmanlar, kimlik doğrulama, yetkilendirme, oturum yönetimi ve veri akışlarını ayrı ayrı inceler.

Ekipler, kapsamı belirlerken genellikle OWASP Top 10 kategorilerini referans alır. Yetkisiz veri erişimi, hatalı yapılandırma, zayıf oturum yönetimi ve girdi doğrulama eksiklikleri bu kategorilerin başında gelir. Modern web uygulamaları artık tek başına çalışmıyor. Üstelik, API entegrasyonları, üçüncü taraf servisler ve kimlik sağlayıcılar uygulamanın saldırı yüzeyini genişletiyor.

OWASP metodolojisi, kapsamın teknik çerçevesini oluşturuyor. Fakat TS 13638, buna ek olarak firmanın nasıl çalışması gerektiğini de tarif ediyor. Tek sayfa uygulamalar ve mobil uyumlu arayüzlerde iş mantığının büyük kısmı istemci tarafında değil, arka uçtaki servislerde çalıştığı için testin ağırlığı API katmanına kayıyor. Modern web teknolojilerindeki hızlı gelişim, güvenlik ekiplerinin test senaryolarını sürekli güncellemesini zorunlu kılıyor. Dolayısıyla, geliştiriciler mikroservis mimarileri ve sunucusuz (serverless) fonksiyonlar gibi yeni yaklaşımları benimsedikçe, güvenlik uzmanları da bu alanlara yönelik özel test metodolojileri geliştiriyor.

Test aşamaları ve Sıklığı

Standart, sürecin denetlenebilir olması adına testleri net aşamalara böler:

• Planlama: Kurum ile firma, test öncesinde gizlilik sözleşmesi imzalar. Test kapsamı (URL’ler, IP’ler), kurallar ve iletişim noktaları netleşir. Kurum ve firma, test yaklaşımını (kara kutu, gri kutu vb.) seçer.
• Uygulama: Otomatik tarama araçları ilk taramayı yapar. Ancak asıl değer manuel testlerde (iş mantığı zafiyetleri, yetkilendirme hataları) ortaya çıkar. Öte yandan, otomatik araçlar iş mantığı hatalarını genelde yakalayamaz.
• Raporlama: Bulgular; yönetici özeti, teknik detay ve risk derecelendirmesiyle sunulur.

Test Sıklığı Ne Olmalı?

Genel kural, yılda en az bir kez test yaptırmaktır. Ancak büyük bir sürüm güncellemesi, yeni bir modül eklenmesi ya da mimari değişiklik, ayrı bir test gerektirir. Sistem her değiştiğinde saldırı yüzeyi de değişir. Düzenleyici kurumların (finans sektörü vb.) talepleri de yıllık ya da altı aylık döngüler zorunlu kılabilir.

Kamu Kurumlarında Farklılıklar

Kamu kurumları için sızma testi bir zorunluluktur. Kritik altyapı işleten kurumlar için sistemler önem derecesine göre gruplandırılır ve kritik olanlar önceliklendirilir. Buna karşın, özel sektörde ise sürücü genellikle müşteri güveni ve sözleşme (iş ortağı) şartlarıdır.

Maliyet, süre ve personel şartları

Kesin bir rakam vermek zordur; çünkü her uygulama farklı bir karmaşıklığa sahiptir. Ekran sayısı, API sayısı ve entegrasyon derinliği süreyi doğrudan etkiler. Basit bir kurumsal web sitesi birkaç günde test edilebilirken, çok sayıda API’ye sahip bir bankacılık uygulaması haftalarca sürebilir. Kısacası, kapsam genişledikçe hem süre hem de maliyet artıyor.

TSE, belge vermeden önce firmanın hem kurumsal hem teknik altyapısını inceler. Uzmanların belirli bir sınavdan geçmesi ya da OSCP, GPEN, CEH gibi sertifikalara sahip olması gerekir. Yıllara dayanan proje tecrübesi ve tamamlanan test sayısı personelin kıdemini belirler.

Ayrıca, bütçe planlaması yapılırken “kapanış doğrulaması” (re-test) maliyeti de hesaba katılmalıdır. Firma seçimi yapılırken en ucuz teklifi değil, kapsamı TS 13638 şartlarına göre en doğru karşılayan teklifi tercih etmek gerekir.

Rapor, Kapanış ve Sık Yapılan Yanlışlar

Bir sızma testinin değeri raporla ölçülür. TS 13638, rapor formatına belirli bir düzen getirir. Yönetici özeti iş etkisini, teknik detay bölümü ise geliştiriciler için açığın adım adım nasıl bulunduğunu anlatır. Bununla birlikte, uzmanlar, her bulguyu bir risk seviyesiyle (Kritik, Yüksek vb.) derecelendirir. Buna ek olarak, raporun teslim edilmesinin ardından, yönetim katmanı risklerin iş sürekliliğine etkisini analiz ederek bütçe ve kaynak planlamasını bu doğrultuda optimize eder. IT ekipleri ise belirlenen kritik bulguları hızlıca kendi geliştirme döngülerine entegre etmelidir. Böylece güvenlik mekanizmaları, sadece yılda bir kez yapılan bir denetim olmaktan çıkıp, operasyonel süreçlerin doğal ve sürekli bir parçası haline gelir.

Sık Yapılan Yanlışlar

• Testi zorunluluk kutucuğu olarak görmek: Raporun alınıp dosyalanması ve bulgular üzerinde çalışılmaması.
• Kapsamı çok dar tutmak: Sadece ana sayfayı test edip arka plandaki API’leri kapsam dışında bırakmak.
• Geliştirme ekibini sürece geç dâhil etmek: Bulguların geliştiricilere test bittikten haftalar sonra ulaşması.
• Düşük riskli bulguları göz ardı etmek: Küçük görünen bir açığın başka açıklarla birleşerek kritik zafiyetlere yol açabileceğini unutmak.
• Testi tek seferlik bir proje sanmak: Aynı sistemi yıllar sonra tekrar test etmeden çalıştırmaya devam etmek.

Kurumlara katkısı ve Nereden Başlanır?

Bu standardın getirdiği en somut fayda, güvenlik açıklarının görünür hâle gelmesidir. Açıkçası, kurum, kendi sistemindeki zayıf noktaları varsayımla değil kanıtla görür. Finans ve kamu sektöründeki kurumlardan denetimlerde TSE belgeli test raporu talep edilmesi, KVKK ve ISO/IEC 27001 ile uyumu destekler.

Nihayetinde, sızma testi güçlü bir araçtır ancak sınırsız değildir. Bir testin bulamadığı açık, sistemde zafiyet olmadığı anlamına gelmez. Test, sürekli izleme araçlarının veya güvenli kod geliştirme pratiklerinin yerine geçmez; sadece bu bütünün doğrulama adımını oluşturur.

Sık Sorulan Sorular