PCI DSS v4.0.1 (Gereksinim 6 ve 11)
Attestkeep, cluster'ınızda admission control ve image taramasının bir dönemde kaydettiklerini 13 maddeye eşler. Kaynak: PCI Security Standards Council, Payment Card Industry Data Security Standard, sürüm 4.0.1 (Haziran 2024). Bunlardan 8 tanesi bu kayıtlardan değerlendirilir; 5 tanesi kapsam dışı işaretlenir, her biri gerekçesiyle.
Cluster'ın cevap verebildiği 8 madde.
Madde numaraları ve başlıklar raporda basıldığı gibi, yani İngilizce. Bir maddeyi açtığınızda ne istediğini, kaynağın kendi ifadesine yakın bir dille okursunuz.
PCI DSS v4.0.1
PCI Security Standards Council, Payment Card Industry Data Security Standard, sürüm 4.0.1 (Haziran 2024)
Gereklilik 6.3 ve 6.5 (zafiyet yönetimi ve değişiklik kontrolü), Gereklilik 10.2 (audit log'lar) ve Gereklilik 11.3 (iç zafiyet taramaları)
| Madde | Başlık | Rapor bölümleri |
|---|---|---|
| Requirement 6.3.1 | Security vulnerabilities are identified and risk-rankedYeni güvenlik zafiyetleri, ulusal ve uluslararası bilgisayar olaylarına müdahale ekiplerinin uyarıları dahil, sektörce tanınmış zafiyet bilgisi kaynaklarıyla belirlenir; ortam için yüksek riskli ya da kritik sayılan tüm zafiyetleri en azından ayırt eden bir risk derecesi verilir. Özel geliştirilmiş yazılımın ve işletim sistemleri, veritabanları gibi üçüncü taraf yazılımın zafiyetleri kapsama dahildir. | CoverageClusterAdmission decisionsOutcomesDeployment contextControl statement |
| Requirement 6.3.2 | Inventory of bespoke, custom and third-party software componentsZafiyet ve yama yönetimini kolaylaştırmak için özel geliştirilmiş yazılımın ve içine katılan üçüncü taraf yazılım bileşenlerinin envanteri tutulur. | Supply chainCoverage |
| Requirement 6.3.3 | System components are protected from known vulnerabilities by patchingTüm sistem bileşenleri, geçerli güvenlik yamaları kurularak bilinen zafiyetlerden korunur: Gereklilik 6.3.1'deki derecelendirmeyle belirlenen kritik zafiyetlerin yamaları yayımlanmalarından sonraki bir ay içinde, diğer tüm geçerli yamalar ise kuruluşun risk kritikliği değerlendirmesine göre belirlenen uygun bir süre içinde kurulur. | Control statementCoverageAdmission decisionsOutcomes |
| Requirement 6.5.1 | Changes to system components follow change control proceduresÜretim ortamındaki tüm sistem bileşenlerinde yapılan değişiklikler belirlenmiş prosedürlere göre yapılır: değişikliğin nedeni ve tanımı, belgelenmiş güvenlik etkisi, yetkili kişilerin belgelenmiş onayı, değişikliğin sistem güvenliğini olumsuz etkilemediğini doğrulayan testler, özel yazılım güncellemelerinin üretime alınmadan önce Gereklilik 6.2.4'e uygunluk açısından test edilmesi ve başarısızlıkları ele alıp güvenli bir duruma dönme prosedürleri. | Admission decisionsEvidence chain |
| Requirement 10.2.2 | What each audit log entry recordsAudit log'lar her denetlenebilir olay için kullanıcı kimliğini, olay türünü, tarih ve saati, başarı ya da başarısızlık bilgisini, olayın kaynağını ve etkilenen verinin, sistem bileşeninin, kaynağın ya da hizmetin kimliğini veya adını kaydeder. | Evidence chain |
| Requirement 11.3.1 | Internal vulnerability scans at least once every three monthsİç zafiyet taramaları en az üç ayda bir yapılır, yüksek riskli ve kritik zafiyetler giderilir, yeniden taramalar giderildiklerini doğrular, tarama aracı güncel zafiyet bilgisiyle tutulur ve taramaları kurumsal olarak bağımsız, yetkin personel yapar. | CoverageAdmission decisionsOutcomesControl statementIssues |
| Requirement 11.3.1.1 | Vulnerabilities not ranked high-risk or criticalDiğer tüm geçerli zafiyetler, kuruluşun hedefli risk analizinde tanımlanan riske göre ele alınır; gerektiğinde yeniden tarama yapılır. | Triage decisionsCoverageDeployment context |
| Requirement 11.3.1.2 | Internal scans are performed via authenticated scanningİç zafiyet taramaları kimlik doğrulamalı yapılır; kimlik bilgisi kabul eden sistemlerde yeterli yetki kullanılır, kabul edemeyenler belgelenir ve kimlik doğrulamalı tarama için kullanılan, etkileşimli oturum açmaya da yarayan her hesap Gereklilik 8.2.2'ye göre yönetilir. | Coverage |
Kapsam dışı işaretlenen 5 madde ve nedenleri
| Madde | Madde ve gerekçe |
|---|---|
| Requirement 6.4.2 | Automated protection for public-facing web applications Bu kontrol hangi image'ın çalışabileceğine karar verir; uygulamanın sonradan yanıtladığı trafiği hiç görmez, web tabanlı saldırı da tam oraya gelir. |
| Requirement 6.4.3 | Payment page scripts are authorised, integrity-assured and inventoried Bir ödeme sayfasının tarayıcıya sunduğu script'ler, uygulamanın runtime'da ürettiği içeriktir; bu kontrolün kabul ettiği image'ın altında kalır ve ona görünmez. |
| Requirement 10.2.1 | Audit logs are enabled and active Log kaydı, kuruluşun ortamında bileşen bileşen açılır; bu belge, bu kontrolün kendi kararları için tuttuğu ve aşağıda 10.2.2'nin raporladığı log'u kanıtlar, geri kalanı hakkında bir şey söyleyemez. |
| Requirement 11.3.2 | External vulnerability scans by an Approved Scanning Vendor Bir ASV, kuruluşun dış saldırı yüzeyini dışarıdan tarar ve ASV Program Guide'a göre raporlar; bu çalışmanın hiçbir yanı bir cluster'ın içinden gözlemlenemez. |
| Requirement 12.3.1 | Targeted risk analysis for a frequency the entity sets 11.3.1.1'in sıklığını belirleyen analiz, kuruluşun yazdığı, onayladığı ve gözden geçirdiği bir belgedir; bu kontrol o analizin vardığı sıklıkta çalışır ve onun yerine geçemez. |
Cluster'ın zaten tuttuğu kayıtlardan kanıt.
Hiçbir şey elle doldurulmaz. Her maddenin cevabında bir durum (karşılanıyor, kısmen, eksik ya da kapsam dışı), dönemin kendi rakamlarını veren bir not ve bu rakamların geldiği rapor bölümleri yer alır.
Eşlemenin dayandığı beyanlar
Değerlendirilen her madde, dönemin kayıtlarıyla ilgili bu beyanlardan bir ya da birkaçıyla cevaplanır. Aynı soruyu her framework'te aynı beyan cevaplar; bu yüzden aynı döneme ait iki rapor birbiriyle çelişemez.
- Envanterdeki her image'ın bir tarama kaydı vardır4 madde
- Ağır bulgu taşıyan image'lar reddedilir3 madde
- Her karar ve her yönetim işlemi kaydedilir2 madde
- Workload dışarıya açık ya da privileged olduğunda zafiyet eşikleri daha sıkıdır2 madde
- Admission uyumsuz workload'ları reddeder1 madde
- Her image değişikliği, onu yöneten policy ile birlikte kaydedilir1 madde
- Kabul edilen risklerin adı, gerekçesi ve süresi var1 madde
- Bulgular, istismar edilen zafiyetlere ait ulusal bir katalogla karşılaştırılır1 madde
- Kritik bulgular için giderme süresi en fazla bir aydır1 madde
- Her önem derecesi için bir giderme süresi tanımlıdır1 madde
- Kullanımdaki image'lar için SBOM tutulur1 madde
- Image'lar, workload'un kendi kimlik bilgileriyle, kimliği doğrulanmış bir pull ile taranır1 madde
Raporda neler var.
Framework hangisi olursa olsun her pakette aynı bölümler bulunur. İşaretli olanlar PCI DSS cevaplarının dayandığı bölümlerdir; her birinin yanında ona dayanan madde sayısı yazar.
- Organisation
- Framework mapping
- Cluster1
- Control statement3
- Coverage6
- Vulnerability findings
- Outcomes3
- Admission decisions4
- Supply chain1
- Triage decisions1
- Break-glass events
- Availability
- Evidence chain2
- Deployment context2
- Issues1
- Ledger
- Population
- Runtime events
- Producer statements (VEX)
Kapsam paragrafı, raporda yazıldığı gibi.
This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto PCI DSS v4.0.1. It is not a Report on Compliance and not an Attestation of Compliance: those are issued by a Qualified Security Assessor or a qualified internal resource against the entity's whole cardholder data environment, and only the entity defines what is in that environment. Nothing here establishes that this cluster is in scope for PCI DSS, or that it is out of it. What the period's records support is the vulnerability management clauses of Requirement 6 and the internal scanning clauses of Requirement 11 for the images this cluster admitted, together with the audit log clauses of 10.2 for the decisions it took. The document records the version of the CISA Known Exploited Vulnerabilities catalogue the period's decisions were taken against, which is one of the industry-recognised sources Requirement 6.3.1 asks for; the mapping below reads the scan and admission records rather than that catalogue directly. Account data at rest and in transit, the web application and payment page clauses of 6.4, the Approved Scanning Vendor scans of 11.3.2 and the organisational programme of Requirement 12 are outside what a cluster observes and are marked as such.
PCI DSS hakkında
Bu bir PCI DSS sertifikası mı?
Hayır. Paket, cluster'ınızın kendi kayıtlarından üretilmiş bir kanıttır. Sertifika değildir ve hiçbir denetçi onu kabul etmek zorunda değildir. Bu sayfadaki kapsam paragrafı, raporun kendisinde yer alan paragrafın aynısıdır.
Maddelerin 5 tanesi neden kapsam dışı?
Bu maddeler, tek bir cluster'ın admission ve tarama kayıtlarının gösteremeyeceği şeyleri soruyor. Rapordan çıkarılmaz, gerekçesiyle listelenir; böylece raporu okuyan kişi bu maddelerin bilerek dışarıda bırakıldığını görür.
PCI DSS hangi planda var?
Her plan bu framework'e göre rapor üretebilir. Community ve Team'de seçtiğiniz bir framework, Business'ta üç, Enterprise'da hepsi bulunur. Fiyatlar fiyat sayfasında.
Denetçi paketi nasıl kontrol eder?
Tarayıcıda, hiçbir şey yüklemeden attestkeep.com/verify.html adresinde ya da dokümantasyon sitesindeki kısa script ile. İkisi de bize ihtiyaç duymaz. Ayrıntılar Denetçiler için sayfasında.
Kendiniz kurun.
Hesap oluşturun, gönderdiğimiz kodla e-postanızı doğrulayın, Licences sayfasından ücretsiz Community anahtarını alın ve Helm ile kurun.
Hesap oluştur