Bir sızma testi, kapsamında yazılı olan soruyu yanıtlar, başka hiçbir şeyi değil. Kapsam "web uygulamamızı test edin" diyorsa, elinize test ekibinin mevcut sürede en ilgi çekici bulduğu şeylere dair bir rapor geçer. Bu da bilmeniz gereken şey olmayabilir.
Çözüm hazırlıktır. Teklif istemeden önce soruyu, kuralları, erişimi, veri işlemeyi ve "bitti" tanımını belirleyin.
Hedefle değil, soruyla başlayın
IP adresleri ve URL'lerden oluşan bir liste hedef listesidir, amaç değildir. Amaç, testin desteklemesi gereken karardır. NIST SP 800-115, teknik güvenlik testlerinin birkaç amaca hizmet ettiğini söyler: örneğin bir sistemde veya ağda zafiyet bulmak ve bir politikaya ya da diğer gereksinimlere uyumu doğrulamak. Bunlar farklı işlerdir ve farklı testler gerektirir.
Amacı, teknik olmayan bir sponsorun okuyup anlayabileceği tek bir cümle olarak yazın. Bazı örnekler:
- Oturum açmış bir müşteri, yeni portalda başka bir müşterinin faturalarını okuyabilir mi?
- Hesabı olmayan bir saldırgan, rezervasyon sisteminin yönetim arayüzüne ulaşabilir mi?
- Uygulama, müşterimizin güvenlik anketinde alıntılanan erişim kontrolü gereksinimlerini karşılıyor mu?
Bunların her biri farklı bir kapsamı, farklı hesapları ve farklı bir raporu gerektirir. Tek bir cümle yazamıyorsanız henüz satın almaya hazır değilsiniz demektir. Teklif istemeden önce test ekibiyle ya da danışmanlık ekibimiz gibi bir danışmanla yapılacak kısa bir kapsam görüşmesi buna değer.
"Test edildi" için bir referans seçin
"Tamamen test edildi" ifadesi, neye karşı test edildiğini söylemediğiniz sürece hiçbir şey ifade etmez. Web uygulamaları için iki OWASP projesi ortak bir dil sağlar.
OWASP Application Security Verification Standard (ASVS), web uygulamalarının teknik güvenlik kontrollerini test etmek için bir temeldir ve geliştiricilere güvenli geliştirme için bir gereksinim listesi sunar. Proje sayfası en son kararlı sürüm olarak 5.0.0'ı gösteriyor. Her gereksinimin numaralı bir tanımlayıcısı vardır ve proje, bu tanımlayıcının sürümle birlikte anılmasını önerir, örneğin v5.0.0-1.2.5. Tanımlayıcılar sürümler arasında değişebildiği için sürüm bilgisi önemlidir.
OWASP Web Security Testing Guide ise nasıl test edileceğini anlatır. Sayfasında güncel sürüm olarak v4.2 görünüyor, 5.0 ise hâlâ geliştirme aşamasında. Sözleşmede beklediğiniz sürümü belirtin, aksi halde iki taraf farklı sürümleri varsayar.
Sonra ASVS'nin hangi bölümlerinin kapsamda olduğunu, seçtiğiniz sürümde göründüğü şekliyle bölüm ve alt bölüm olarak yazın. Örneğin v5.0.0-1.2.5 tanımlayıcısı, "Encoding and Sanitization" bölümünün "Injection Prevention" alt bölümündeki 5. gereksinimi gösterir. Amacınıza uyan alt bölümleri seçin ve bulguların gereksinim tanımlayıcılarıyla eşleştirilmesini isteyin. Bu, yeniden testi ve geliştiricilerin takibini çok daha kolaylaştırır.
Çalışma kuralları (rules of engagement)
Çalışma kuralları, test ekibinin neler yapabileceğine dair yazılı sınırlardır. Bunlar kaynakların öngördüğü şeyler değil, bizim önerilerimizdir, ancak her kapsam belgesi şu konuları netleştirmelidir:
| Madde | Karar verilecek konu |
|---|---|
| Ortam | Canlı ortam, test ortamı (staging) veya ikisi birden. Staging daha güvenlidir ama yalnızca canlı ortamın yapılandırmasıyla eşleşiyorsa işe yarar. |
| Zaman aralığı | Tarihler ve saatler, ayrıca testin mesai saatleri dışında yapılıp yapılamayacağı. |
| Kaynak adresler | İzleme ekibinizin test ekibini gerçek bir saldırgandan ayırt edebilmesi için test ekibinin kullanacağı IP'ler. |
| Hariç tutulan teknikler | Hizmet engelleme (denial of service), sosyal mühendislik ve fiziksel erişim sık görülen hariç tutmalardır. Her iki durumda da yazılı hale getirin. |
| Durdurma koşulları | Test ekibinin çalışmayı duraklatmasını gerektiren durumlar: bir kesinti, beklenmedik kişisel verilere erişim, kritik bir bulgu. |
| İletişim kişileri | Her iki tarafta da isimleri belli iki kişi ve geceleri de çalışan telefon numaraları. |
SOC ekibinizin testten haberdar edilip edilmeyeceğine önceden karar verin. Haberdar etmek süreci test eder, sessiz tutmak ise tespit yeteneğini test eder. İkisi de geçerlidir, ancak bilinçli bir seçim yapmalısınız.
Test hesapları ve veri işleme
Hesap sağlayın, çünkü oturum açamayan bir test uzmanı, oturumun arkasında kalanı inceleyemez. Uygulamadaki her rol için bir hesap verin, ayrıca farklı müşterilere veya kiracılara (tenant) ait, aynı roldeki iki hesap ekleyin. Bu çift olmadan, bir kullanıcının başka birinin verisine ulaşıp ulaşamadığını kimse kontrol edemez.
Hesapları önceden oluşturun, giriş yapabildiklerini test edin ve çok faktörlü kimlik doğrulamanın nasıl ele alınacağını belirtin.
Veri işlemeyi sözleşmede kararlaştırın:
- Mümkün olduğunda staging ortamında sentetik veri kullanın. Canlı ortam kapsamdaysa, test ekibinin hangi gerçek kayıtları görüntüleyebileceğini ve hangilerini görüntüleyemeyeceğini belirtin.
- Ekran görüntüleri, istek günlükleri ve çıkarılan veriler gibi kanıtların nerede saklanacağını, kimlerin erişebileceğini ve test ekibinin bunları ne kadar süre tutacağını belirtin.
- Raporun kendisinin şifreli olarak iletilmesini şart koşun. Rapor, zayıflıklarınızın listesidir.
- Hassas bulgular için kuralı belirleyin: test ekibi kişisel verilerle karşılaşırsa durur, içeriği kopyalamadan konumunu kaydeder ve sizin iletişim kişinizi arar.
Başarı ölçütleri ve raporlama
"Kritik bulgu yok" bir başarı ölçütü değildir. Yüzeysel bir testi ödüllendirir. "Bitti"yi kapsam ve çıktı kalitesi olarak tanımlayın: kararlaştırılan gereksinimler incelendi ve her bulgu, yeniden üretilip düzeltilebilecek yeterlilikte ayrıntıyla geliyor.
NIST, kılavuzunu testleri yürütmenin yanı sıra bulguları analiz etmeye ve azaltım stratejileri geliştirmeye yardımcı olan bir belge olarak tanımlar. Siz de aynısını isteyin. Her bulgu; yeniden üretme adımlarını, etkilenen bileşeni, sonucu kendiniz de doğrulayabilmeniz için yöntemi belirtilmiş bir önem derecesini ve somut bir düzeltme önerisini içermelidir. Düzeltilen bulgular için bir yeniden testi teklife ekleyin ve raporu kimin, ne zaman kabul edeceğini kararlaştırın.
Sızma testi hizmetimiz gibi bir sağlayıcıdan satın alıyorsanız, bu maddeleri yalnızca açılış toplantısında değil, iş tanımı belgesine (statement of work) de yazın.
Nereden başlamalı
- Amacı tek bir cümle olarak yazın ve iş sahibinin onaylamasını sağlayın.
- Kapsamdaki uygulamaları, ortamları ve rolleri listeleyin; kapsam dışı olanları açıkça belirtin.
- Referansı seçin: kapsamdaki ASVS bölümleri ve alt bölümleri ile bir Web Security Testing Guide sürümü, hepsi sürüm numaralarıyla yazılmış olsun.
- Çalışma kuralları tablosunu doldurun; iletişim kişilerini, zaman aralığını ve kaynak adresleri unutmayın.
- Test hesaplarını oluşturup doğrulayın, farklı kiracılar için aynı roldeki iki hesap da buna dahil, ve veri işleme kurallarını belirleyin.
- Başarı ölçütlerini sözleşmeye yazın: bulgu formatı, önem derecesi yöntemi, gereksinim tanımlayıcılarıyla eşleştirme ve bir yeniden test.
