Yetkili sızma testi için güvenli ve ölçülebilir test ortamı

1. Testin amacı ve yetkisi baştan açık olsun

Önce cevap aranan soruyu tanımlayın: iki müşteri birbirinin kaydını görebiliyor mu, yönetici işlemleri denetlenebiliyor mu, şube yönetim arayüzüne gereksiz erişim var mı? Dar ve ölçülebilir sorular, test ekibinin bulgusunu geliştiricinin veya ağ yöneticisinin somut işine bağlar. Bir tarama raporu, kaynak kod incelemesi ve sızma testi farklı kapsamlar sunar; satın alma dosyasında bunları aynı hizmetmiş gibi yazmayın.

NIST SP 800-115, güvenlik değerlendirmesinin planlanmasını, bulguların analizini ve iyileştirme adımlarını ele alır; Ek B, çalışma kuralları için bir başlangıç şablonu sunar. [1] Yazılı yetkide sistem sahibi, kapsamdaki varlıklar, zaman aralığı, izin verilen faaliyetler, yasak alanlar, veri işleme kuralları ve durdurma yetkilisi açık olmalıdır. Bulut veya üçüncü taraf hizmeti kullanılıyorsa onların ilgili test politikaları ayrıca doğrulanmalıdır.

2. Eğitim laboratuvarını üretimden ayırın

Kontrollü bir laboratuvar; test cihazları, hedef uygulama ve gözlem bileşenlerinden oluşabilir. Ayrı sanal ağ ve erişim kurallarıyla üretim sistemlerine geçiş engellenmeli, dış bağlantılar yalnızca gereken hizmetlerle sınırlandırılmalıdır. Yönetim erişimi de ayrı tutulmalıdır. Bir sanal makine etiketi veya farklı IP aralığı kendi başına izolasyonun çalıştığını kanıtlamaz; izin verilen ve engellenmesi gereken yollar kontrol edilmelidir.

Eğitim amacıyla kasıtlı zayıflık içeren uygulamalar kullanılabilir; OWASP Juice Shop böyle bir eğitim projesidir. [2] Bu tür bir hedefi müşteri verisiyle doldurmak veya herkese açık üretim sunucusuna koymak uygun bir laboratuvar tasarımı değildir. Kendi yönetiminizde, erişimi sınırlandırılmış bir ortam oluşturun. Eğitimde kazanılan beceriler, üçüncü tarafların sistemlerini test etmek için yetki sağlamaz. Bu rehber de dış sistemlere yönelik test talimatı içermez.

3. Veri ve kimlikler laboratuvara ait olsun

Sentetik müşteri, sipariş ve kullanıcı kayıtlarıyla çalışın. Gerçek veri zorunluysa kurumun veri sorumlusu tarafından onaylanmış bir yöntem ve dar erişim kapsamı kullanın; mümkün olan yerlerde maskeleme veya veri azaltma uygulayın. Üretimde çalışan API anahtarları, parolalar ve ödeme bilgileri test kopyasına taşınmamalıdır. Test için açılan hesapların sahibi, rolü ve kapanış zamanı belli olmalıdır.

Yetki denetimi için farklı rollerde ve farklı örnek müşterilerde hesaplar gerekir. OWASP'ın yetkilendirme testi yaklaşımı, roller ile işlemler arasındaki beklenen izinleri açık bir matriste toplamaya yardımcı olur. [3] Örneğin bir rolün yalnızca kendi kaydını okuyabilmesi bekleniyorsa, testin sonucu ve uygulama günlüğündeki karşılığı birlikte kaydedilir. Amaç gerçek kişinin bilgisini ele geçirmek değil, tanımlı sınırın çalışıp çalışmadığını kontrollü verilerle doğrulamaktır.

4. Tekrarlanabilir bir başlangıç ve gözlem düzeni kurun

Uygulama sürümü, yapılandırma, test verisi ve ağ kurallarını başlangıç kaydına ekleyin. Deneme bittikten sonra ortamın nasıl temiz duruma getirileceği belli olmalıdır. Anlık görüntü bu işte yardımcı olabilir, fakat bağlı dış hizmetlerin veya harici veri depolarının durumunu otomatik olarak geri almayabilir. Geri alma planı, test edilen sistemin bütün bağımlılıklarını kapsamalıdır.

Saatleri uyumlu günlükler, işlem kaydı ve gerektiğinde hassas verisi azaltılmış ekran kanıtı kullanın. Kanıt dosyaları yalnızca yetkili ekibe açık olmalı; saklama süresi ve silme sorumlusu belirlenmelidir. Testi durdurma ölçütlerini de pratik seçin: beklenmeyen üretim bağlantısı, kapsam dışı veri veya kabul edilmeyen hizmet etkisi görülürse faaliyet durur ve sorumlu kişi bilgilendirilir. Gözlem, denemenin hem güvenliğini hem de sonradan anlaşılabilirliğini artırır.

5. Bulgu, düzeltme ve yeniden test aynı zincirde

OWASP Web Security Testing Guide, güvenlik testini geliştirme yaşam döngüsüyle ilişkilendirir; tek bir araç bütün güvenlik sorunlarını kapsamaz. [4] Raporda yalnızca önem derecesi yazmak yerine etkilenen iş akışını, ön koşulları, gözlenen sonucu ve önerilen kontrolü anlatın. Bir yönetici özeti karar vermeyi kolaylaştırmalı, teknik ek ise yetkili ekibin bulguyu yeniden değerlendirmesine yetecek kadar açık olmalıdır.

Düzeltme sonrasında aynı soruyu yeni sürüme tekrar sorun ve normal kullanıcı akışının da bozulmadığını kontrol edin. Her bulgu için sorumlu, hedef tarih ve kabul koşulu belirlemek, raporun arşivde kalmasını önler. Laboratuvarda başarılı sonuç almak üretimdeki bütün risklerin giderildiği anlamına gelmez; ortam farklarını raporlayın. MyFi Business ile ağ ve erişim tasarımı değerlendirilirken test ortamının bağlantı, izolasyon ve teknik koordinasyon ihtiyaçları da ayrıca kapsamlandırılabilir.

6. Çalışmaya başlamadan kontrol edin

Aşağıdaki kayıtlar hazır olmadan teknik çalışma başlatılmamalıdır. Bir maddede değişiklik yapılırsa kapsam sahibi ve uygulayıcı ekip aynı güncel belgeyi kullanmalıdır.

• Yazılı yetki, varlık listesi, zaman aralığı ve durdurma kişisi mevcut mu?
• Üçüncü taraf ve bulut hizmeti koşulları doğrulandı mı?
• Laboratuvarın üretime ve gereksiz dış hedeflere erişimi sınırlandı mı?
• Sentetik veri, ayrı test hesapları ve başlangıç yapılandırması hazır mı?
• Kanıt erişimi, saklama, temizleme ve geri alma sorumluları belli mi?
• Rapor, düzeltme ve yeniden test teslimleri kapsamda açıkça yer alıyor mu?