[ This article was originally published here ]
Bu, bir AT&T Siber Güvenlik danışmanı tarafından yazılan, PCI DSS’ye odaklanan serideki ikinci blog. IAM ve PCI DSS ile ilgili ilk bloga bakın .
PCI DSS Standardında ve bununla ilişkili Uyum Raporunda ima edilen ve uygulamada nadiren ele alınan birkaç konu vardır. Bu, değerlendirmek zorunda kaldığım sızma ve güvenlik açığı testi raporlarında sıklıkla meydana gelir.
Metodoloji
İlk olarak, değerlendirmeyi talep eden kuruluşun yazılı politikaları ve prosedürleriyle eşleşen bir metodolojidir. Müşteri tarafından değil, sağlayıcı tarafından dikte edilen metodolojiyi sık sık görüyorum. Bir müşteri olarak (muhtemelen farklı sağlayıcılardan) en azından şunları istemelisiniz:
- Dahili ve harici ağ güvenlik açığı testi
- Hem uygulama hem de ağ katmanları için dahili ve harici sızma testi
- Segmentasyon testi
- API penetrasyon testi
- Web uygulaması güvenlik açığı testi.
Başvuru
Bu tür testlerin her birinin daha sonra . Genel olarak, test cihazına bir URL listesi veya IP adresleri listesi sağlarsınız. PCI, ödeme sayfalarıyla ilişkili herkesin erişebileceği tüm varlıkların test için gönderilmesini gerektirir. Dinamik IP ataması, özellikle Bulut ortamlarında çok yaygın olmakla birlikte, üç aylık test siparişlerinde tutarlı bir adresleme bilgisi seti sağladığınızdan emin olun.
ASV taramaları
Taramaların hem sizin hem de ASV tarafından onaylanmış taramalar olduğundan ve tarama raporunun neyin tarandığını ve sonuçları bilmek için yeterli ayrıntıyı gösterdiğinden emin olun. İlk iki özet sayfası, taranan varlıkların bir miktarını ve bulunan bir miktarı verebildikleri, ancak neyin tarandığına dair belirli bir bilgi vermedikleri için değerlendiricinin çalışması için nadiren yeterlidir.
Dahil olanları bildir
Test sağlayıcısına raporların her birinin içermesi gerektiğini belirtmeniz gerekecektir.
- Testi yapan kişinin kimlik bilgileri ve önceki 12 ay içinde uygun eğitimi gösteren eğitim kaydı
- Testleri gerçekleştiren dahili bir kaynaksa, bunların test edilen ekipmanı yöneten kuruluştan nasıl bağımsız olduklarını raporda açıklayın. (Örneğin, yöneticiler CIO’ya, test uzmanları CTO’ya rapor verir, ancak bu, test uzmanları ve geliştiricilerin aynı kuruluşta olduğu ve bağımsız olmaları gerekmediği anlamına gelebilir).
- Önceki test tamamlama tarihi (“en az üç ayda bir” (veya yıllık) yürütmeyi kanıtlamak için).
- Geçerli test yürütmesinin tarihleri.
- Düzeltme testinin tarihleri ve tam olarak neleri kapsadığı ve yeni sonuçların bir özeti (yalnızca eski sonuçların yeniden yazılması, Nitelikli Güvenlik Değerlendiricisinin (QSA) değerlendirme sırasında tanıması için çok zordur).
- Tüm URL’ler ve IP adresleri kapsanır ve bulut platformlarındaki gibi dinamik DNS atamaları için yapılan her türlü düzenlemeyi, herhangi bir kaldırmayı veya önceki testten envantere eklemeleri (kullanımdan kaldırılan platformlar, bakımda ve bu nedenle keşfedilmemiş, küme eklemeleri vb.) açıklar. .). Planlanan test sırasında bakım altında olan tüm varlıklar, tekrar çevrimiçi olur olmaz bir teste tabi tutulmalıdır, aksi takdirde önemli süreler boyunca test edilmeden zayıflayabilirler.
- Sonuçlarının rapora dahil edildiği, ancak aslında CDE’nin kapsamının bir parçası olmayan ve bu nedenle kapsam içi bir cihazın ihtiyaç duyduğu düzeltmelere ihtiyaç duymayabilecek tüm kaynakları açıklayın (örn. CDE’ye bitişik ağlardaki yazıcılar) .
- Test yoluyla bulunan ve başarısızlık olarak kabul edilen sorunların neden genel güvenlik duruşuyla ilgili olmadığı açıklamaları. (Bu, test raporunun bir parçası yerine dahili olarak oluşturulmuş olabilir).
- Önceki yıl boyunca ortaya çıkan şüpheli ve doğrulanmış güvenlik sorunları, test uzmanı tarafından raporda listelenir ve testin bu sorunların yeterince çözüldüğünü nasıl doğruladığına dair bir açıklama içerir. En azından, Kritik Müdahale Ekibi tarafından ele alınan her şey buraya dahil edilmelidir.
- PCI gereksinimlerini doğrulamak için herhangi bir ek metodoloji (özellikle segmentasyon için ve testin kullanımdaki tüm segmentasyon yöntemlerini nasıl kapsadığı).
PCI DSS 4.0 eklemeleri
Gelecekteki PCI DSS 4.0 değerlendirmelerinde, test cihazlarının ayrıca test araçlarının güncel olduğunu ve mevcut tüm verileri taklit edebildiğini kanıtlaması gerekir. ve ortaya çıkan saldırılar. Bu, bir QSA’nın pratik olarak hiçbir şeyle karşılaştıramayacağı 100 sayfalık eklenti revizyonları anlamına gelmez. Test ve test edilen sistem bileşen revizyon seviyesi doğrulaması için yeni bir paradigmanın test endüstrisinde geliştirilmesi gerekecektir.
Kimlik bilgileri içeren dahili güvenlik açığı taramaları, PCI DSS 4.0 gereksinimi 11.3.1.2 tarafından da gereklidir. Bu, test kullanıcı kimliğine atanacak rol(ler)in ve ayrıcalık(lar)ın oluşturulmasını gerektirir; buna gereksinim başına, teste süper kullanıcı yetenekleri vermeden anlamlı testler sağlamak için yeterli düzeyde ayrıcalık dahildir. test için oluşturulan hesaplar ve altı ayda bir rolün ve kimlik bilgilerinin yönetim tarafından doğrulanması. Gereksinim 8 kontrolleri, test için oluşturulan kimlik bilgileri için de geçerlidir. Bunlar arasında, bunlarla sınırlı olmamak üzere, minimum 12 karakterlik parolalar, benzersiz parolalar, ilişkili kullanıcı kimliklerinin etkinliğinin izlenmesi ve kullanılmadığında hesapların devre dışı bırakılması yer alır.
reklam