PCI DSS 4.0 Anforderungen: Ein tiefer Einblick in die neuesten Änderungen und deren Auswirkungen auf Ihr Unternehmen
Die neueste Version des Payment Card Industry Data Security Standard — PCI DSS 4.0 — wurde am 31. März 2022 veröffentlicht und ist derzeit in Kraft. Am 31. März 2024 wird sie die einzige gültige Version sein.
Bis zum 31. März 2025 müssen Organisationen auch Anforderungen übernehmen, die in v4.0 als zukünftiges Datum identifiziert wurden.
Um diese Compliance-Deadlines zu erfüllen, müssen Organisationen, die Karteninhaberdaten speichern, verarbeiten, übertragen oder die Sicherheit dieser Daten beeinflussen:
- die Änderungen in v4.0 überprüfen
- neue Kontrollen implementieren, um die aktualisierten und neuen Anforderungen in v4.0 zu erfüllen
- ihre Berichterstattungsvorlagen und -formulare aktualisieren
- anfangen, zukunftsorientierte Anforderungen zu implementieren, die spätestens bis zum 31. März 2025 bewertet werden müssen.
Dies kann schwer alleine zu bewerkstelligen sein. Deshalb haben Marc Rubbinaccio, ein ehemaliger QSA und derzeit der Fachexperte für PCI DSS bei Secureframe, und Jonathan Smith, ein QSA bei Moss Adams, am 11. Mai ein Secureframe Expert Insights-Webinar veranstaltet.
Sie boten einen tiefen Einblick in die bedeutendsten Änderungen für PCI DSS 4.0 und Ratschläge, wie Sie diese einhalten können. Lesen Sie weiter oder sehen Sie sich das Video auf Abruf an, um ihre Einsichten zu erhalten.
PCI DSS 4.0 vs 3.2.1 Anforderungen
Da sich die Technologie- und Bedrohungslandschaften rasant weiterentwickeln, müssen auch die Sicherheitsrahmenwerke, die Organisationen vor Sicherheitsvorfällen und -verletzungen schützen sollen, Schritt halten. Deshalb werden Rahmenwerke wie PCI DSS regelmäßig aktualisiert.
Obwohl es schwierig sein kann, mit den neuesten Änderungen der PCI DSS-Compliance-Anforderungen Schritt zu halten, sind Organisationen, die sich anpassen, am besten in der Lage, Zahlungsdaten zu schützen.
Nachfolgend sind die wesentlichen Unterschiede zwischen PCI DSS v4.0 und v3.2.1 aufgeführt und warum Sie die neueste Version einhalten sollten.
1. Ständige Weiterentwicklung
Eines der Hauptziele von PCI DSS 4.0 ist es, den Standard weiterzuentwickeln, um den sich ändernden Bedürfnissen der Zahlungsverkehrsindustrie und den täglich implementierten neuen Technologien gerecht zu werden. Deshalb enthält PCI DSS 4.0 Updates zu Anforderungen an Multi-Faktor-Authentifizierung, Passwörter und Sicherheitsbewusstsein sowie neue Anforderungen für den E-Commerce.
Anforderungen an Multi-Faktor-Authentifizierung und Passwörter
Ein großes Diskussionsthema in der Sicherheitsgemeinschaft ist, wie man die Authentifizierung am besten sichert, ohne die Fähigkeit der Benutzer zu beeinträchtigen, sich in Systeme einzuloggen und tatsächliche Arbeit zu leisten.
Ein gutes Beispiel dafür ist, dass das NIST seine Passwortanforderungen vor ein paar Jahren überarbeitet hat, um speziell darauf einzugehen, wie Passwörter in der realen Welt gehackt wurden. PCI DSS 4.0 hat die Authentifizierungsanforderungen verbessert und zwingt alle Benutzer, die auf die Umgebung mit Karteninhaberdaten zugreifen, zur Multi-Faktor-Authentifizierung, nicht nur Administratoren. Die Anforderungen an die Passwortlänge wurden ebenfalls von 8 auf 12 Zeichen erhöht. Schließlich gibt PCI DSS den Organisationen nun die Möglichkeit, eine dynamische Analyse zu verwenden, um automatisch den Zugang zu Ressourcen zu bestimmen, anstatt alle Passwörter alle 90 Tage ändern zu müssen.
Sicherheitsbewusstseinsanforderungen
Sozialtechnik und insbesondere Phishing sind nach wie vor eine der häufigsten Methoden, mit denen Angreifer auf Systeme zugreifen und Karteninhaberdaten stehlen. Egal wie stark Ihre Cloud- und Anwendungssicherheitskonfigurationen sind, wenn ein Mitarbeiter mit Zugang zu sensiblen Daten auf einen Spear-Phishing-Angriff hereinfällt, könnten Hacker denselben Zugang erhalten und beginnen, Karteninhaberdaten zu verlieren.
Infolgedessen stärkt PCI DSS seine Haltung zu Sicherheitsschulungen, indem es spezifische Bedrohungen und Schwachstellen in die Schulungsprogramme der Organisationen einbezieht. Wenn Sie beispielsweise ein E-Commerce-Händler sind und Unterstützung über Chats anbieten, sollten Ihre Support-Mitarbeiter sich der spezifischen Arten von Phishing-Angriffen bewusst sein, die über Live-Chats auftreten könnten.
Sicherheitsbewusstseinsschulungen müssen auch jährlich überprüft und aktualisiert werden, basierend auf Änderungen in der Umgebung oder potenziellen Risiken.
Eine weitere Ergänzung zu den Anforderungen an das Sicherheitsbewusstsein ist die Festlegung der akzeptablen Nutzung aller Endbenutzertechnologien, einschließlich des Zugriffs und der Nutzung von Workstations und des Verständnisses der Konsequenzen bei Nichteinhaltung dieser akzeptablen Nutzungsrichtlinien.
E-Commerce-Anforderungen
Eine der größten und bedeutendsten Änderungen in PCI DSS 4.0 betrifft die Verwaltung und Handhabung von Skripten auf Zahlungsseiten und zahlungsnahen Seiten.
Vor PCI DSS 4.0 gab es keine spezifischen Anforderungen an die Handhabung von Skripten, die in den Browsern der Verbraucher ausgeführt und geladen werden. Dies führte zur Verbreitung von Magecart-Angriffen, die sich hauptsächlich auf E-Commerce-Händler konzentrierten. Hacker injizierten ihren eigenen Code in Zahlungsseiten, um die Karteninhabeformulare zu kapern oder Verbraucher auf bösartige Websites umzuleiten.
2. Förderung der kontinuierlichen Sicherheit
Ein weiteres Ziel von PCI DSS v4.0 ist die Unterstützung langfristiger, kontinuierlicher Prozesse zum Schutz von Zahlungsdaten.
Ein häufiges Problem bei Organisationen, die PCI-Compliance anstreben, ist, dass sie stark in die Implementierung von Prozessen, Verfahren und Konfigurationen kurz vor ihrer Bewertung investieren - dann erhalten sie ihre Zertifizierung und PCI DSS wird für die nächsten 11 Monate zur Nebensache. Infolgedessen verpassen viele Organisationen, die eine Rezertifizierung anstreben, regelmäßige Überprüfungen im Laufe des Jahres aufgrund von schlecht organisierten Kontrollen. Dies kann entweder zu einer Nichteinhaltung von PCI führen oder der Prüfer muss einen kompensierenden Kontrollmechanismus entwerfen, basierend darauf, wie die Organisation diese Kontrolle im kommenden Jahr übertreffen würde.
Eine große Lücke, die PCI DSS 4.0 schließen will, ist die Stärkung der Zuordnung von Verantwortlichkeiten für Sicherheitskontrollen. Nun muss die Organisation angeben, wer in der Organisation für die Einhaltung dieser Kontrolle verantwortlich ist und alle anderen PCI DSS-Sicherheitskontrollen vorantreibt, anstatt nur festzulegen, dass vierteljährliche Schwachstellenscans durchgeführt werden.
Ein weiterer zuvor übersehener Aspekt ist die PCI DSS-Reichweite. Die Abgrenzung Ihrer Umgebung mit Karteninhaberdaten ist entscheidend, um sicherzustellen, dass alle relevanten Ressourcen und Mitarbeiter in den Umfang des Audits sowie in den Umfang aller erforderlichen Sicherheitskontrollen, Konfigurationen und Überprüfungen einbezogen sind. Zuvor, wenn während des Auditzeitraums Änderungen vorgenommen werden, die Ihren Umfang betreffen könnten, würde der Prüfer dies erst entdecken, wenn das Audit des nächsten Jahres kurz vor dem Beginn steht. Mit PCI DSS 4.0 muss eine Organisation nun ihren PCI DSS-Umfang das ganze Jahr über überprüfen und dokumentieren. Dies stellt sicher, dass die Organisation die PCI DSS-Compliance genau einhält.
3. Ermöglichen von Flexibilität
Um Organisationen zu helfen, Sicherheit als kontinuierlichen Prozess zu priorisieren, bietet PCI DSS 4.0 auch zusätzliche Flexibilität. Diese Flexibilität soll es den Organisationen ermöglichen, Sicherheitskontrollen auszuwählen, die am besten zu ihren geschäftlichen und sicherheitstechnischen Anforderungen passen. Dies spiegelt sich in zwei wesentlichen Weisen in PCI DSS 4.0 wider.
Eine bedeutende Änderung in PCI DSS 4.0 besteht darin, die Denkweise von Organisationen im Hinblick auf das Risikomanagement zu ändern. Bisher waren Organisationen verpflichtet, eine vollständige jährliche Risikobewertung sowie Intervalltests durchzuführen, die von PCI DSS definiert wurden, wobei einige Aufgaben täglich, halbjährlich oder vierteljährlich durchgeführt werden mussten. Mit PCI DSS 4.0 sollte nicht nur eine vollständige jährliche Risikobewertung durchgeführt werden, sondern auch die Intervalltests können jetzt speziell von der Organisation basierend auf dem Risiko definiert werden. Zum Beispiel können Zugriffsüberprüfungen jetzt in einem regelmäßigen Intervall durchgeführt werden, das für die Organisation basierend auf dem definierten Risiko am sinnvollsten ist.
PCI DSS 4.0 führte auch den angepassten Ansatz ein, eine zweite Methode, mit der Einheiten die strengen PCI DSS-Anforderungen erfüllen können. Der angepasste Ansatz bietet Organisationen die Flexibilität, die Sicherheitsziele der PCI DSS-Anforderungen mit neuer Technologie und innovativen Kontrollen zu erfüllen. Der Prüfer wird validieren, dass die angepassten Kontrollen die PCI DSS-Anforderungen erfüllen, indem er die Dokumentation des angepassten Ansatzes der Organisation überprüft und ein Verfahren entwickelt, um zu validieren, dass die Kontrollen durch den angepassten Ansatz erfüllt werden.
Um klarzustellen, dies erfordert zusätzliche Arbeit und Dokumentation von der Organisation. Es wird letztendlich einfacher sein, die Anforderungen wie von PCI DSS definiert zu erfüllen, aber einige reife Organisationen können sich für einen angepassten Ansatz entscheiden.
4. Verbesserte Validierung
Eine weitere wesentliche Änderung, die durch PCI DSS vorgenommen wurde, besteht darin, jetzt zuzulassen, dass Organisationen Teilbewertungen durchführen.
Bisher wurde die Organisation automatisch als nicht konform angesehen, wenn eine Anforderung vom Auditor nicht getestet wurde. Mit PCI DSS 4.0 haben Organisationen nun die Flexibilität, nur einen bestimmten Aspekt ihres Dienstes auf Anfrage eines Kunden zu testen, und ein QSA wird bestätigen, dass die getesteten Kontrollen PCI DSS-konform waren.
Empfohlene Lektüre
PCI-Geschichte: Wie der Standard entstand
Was bedeuten diese Änderungen für Ihre Organisation und wie soll darauf reagiert werden?
Egal, ob Sie bereits PCI-zertifiziert sind oder zum ersten Mal eine PCI-Zertifizierung anstreben, sollten Sie die folgenden Schritte unternehmen, um mit dem Übergang zu PCI DSS v4.0 zu beginnen.
1. Verstehen Sie die neuen Anforderungen und Änderungen der bestehenden Anforderungen
Um Ihre Reise zu PCI DSS v4.0 zu beginnen, lesen Sie die PCI DSS 4.0-Dokumentation für einen detaillierten Vergleich jeder Änderung und jedes neuen Controls.
Wenn Sie ein Secureframe-Kunde sind, wenden Sie sich an Ihren Compliance-Manager, um eine ausführliche Diskussion über Ihre aktuelle Umgebung und Ihren Umfang zu führen, um festzustellen, welche Kontrollen für Sie gelten.
Sie können auch das Fachwissen Ihres QSA und deren Erfahrung mit Ihrer Umgebung nutzen. Wenn Sie derzeit keinen QSA haben, verfügt Secureframe über ein Netzwerk von Audit-Partnern, die wir Ihnen vorstellen können.
2. Überprüfen Sie den Zeitplan für die Umsetzung
Da nicht alle Anforderungen bis 2024 erfüllt sein müssen, ist es wichtig, die Kontrollen basierend auf den Umsetzungszeitplänen zu priorisieren. Sie müssen verstehen, welche Kontrollen für PCI DSS 4.0-Bewertungen sofort wirksam sind und diese priorisieren, damit Sie für 2024 vorbereitet sind. Anschließend müssen Sie die Kontrollen für zukünftige Anforderungen in 2025 verstehen und priorisieren.
3. Erstellen Sie einen Plan
Um einen reibungslosen Übergang zu PCI DSS 4.0 zu gewährleisten, erstellen Sie einen soliden Plan, einschließlich eines Implementierungszeitplans mit zugewiesenen Verantwortlichen für alle Richtlinien, Prozesse und Konfigurationsänderungen, die für PCI DSS 4.0 erforderlich sind. Priorisieren Sie die Anforderungen mit der größten Auswirkung und die Anforderungen mit dem frühesten Implementierungsdatum.
Empfohlene Lektüre
Schneller PCI DSS-Konformität mit Secureframe
PCI DSS 4.0 Anforderungen und wie man sie erfüllt
Mit den Änderungen in PCI DSS 4.0 stehen Organisationen vor der Herausforderung, bis März 2024 Hunderte von aktualisierten oder neuen Anforderungen und bis März 2025 zukunftsdatierte Anforderungen zu erfüllen. Um zu helfen, haben wir einen Überblick über die wichtigsten PCI DSS 4.0 Anforderungen und Leitlinien für die Einhaltung in den untenstehenden Tabellen bereitgestellt.
| Must be performed immediately for all 4.0 assessments | What changed? | How to meet this requirement |
|---|---|---|
| All Requirement Sections | Roles and responsibilities for performing activities in each requirement must be documented, assigned, and understood. | Use a responsibility assignment matrix to assign owners. Can be done within a platform like Secureframe. |
| Requirement 8 | Increased the number of invalid authentication attempts before locking out a user ID to ten attempts. | Set threshold for invalid authentication attempts before locking out to ten attempts. |
| Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days. | Use dynamic analysis, a solution that takes multiple data points and determines in real time if an account should gain access. | |
| Requirement 9 | Restrict access to consoles in sensitive areas via locking when not in use. | Lock the login screens of consoles when not in use. |
| Requirement 12 | Added requirement for personnel to formally acknowledge their responsibilities. | Include the security responsibilities of all roles within the organization in your information security policy. |
| Perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach. | Implement a controls matrix and risk analysis for controls being met via customized approach (see appendix D/E of PCI 4.0 for more information). | |
| Document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. | Develop a document that contains info related to the storage of CHD (purpose, retention, elements, access, encryption), internal systems and apps consisting of the CDE, and connections to vendors or third parties. | |
| Service providers must support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5. | Document a process for obtaining PCI AOC’s from third-party service providers as well as a plan for receiving evidence in case the TPSP is not PCI compliant. |
| Future-dated requirements effective in 2025 | What changed? | How to meet this requirement |
|---|---|---|
| Requirement 3 | Include locations of stored SAD prior to authorization in data retention / disposal policies, procedures and processes. | Inventory SAD data flows to understand where it goes (will involve product/development). |
| Issuers must define business justification for the storage of sensitive authentication data. | In a policy or similar document, state the instances of stored sensitive authentication data, and the justification for the storage of that data. | |
| Encrypt SAD that is stored electronically prior to authorization. | Utilize the same processes to encrypt SAD that is used for PAN (but consider utilizing different keys for SAD vs PAN). | |
| Establish technical controls to prevent copying of PAN when using remote-access technologies. Document a list of personnel allowed to copy or relocate PAN data. | Identify a solution that will help stop the copying of PAN. Can be DLP, PCoIP, blocking of copy/paste functions over RDP, etc. | |
| When hashing is used to render PAN unreadable, ensure all aspects of the hash is documented and the hashing method results in keyed cryptographic hashes of the entire PAN. | When hashing, use cryptographic keys. | |
| If disk level/partition level or transparent encryption is used to render PAN unreadable, it must only be used on removable media devices. | If your cloud solution uses transparent encryption (i.e. the decryption process is tied with user access such that data is automatically encrypted), implement an additional layer of encryption. | |
| Service providers must document the prevention of shared cryptographic keys between production and test environments. | Document how keys are different between production and test environments. | |
| Requirement 4 | Any certificates used to protect PAN data over open / public networks must be confirmed to be valid and not expired. All certificates and trusted keys must be maintained in a documented inventory. | Inventory all card flows over the Internet. Document where you control the encryption (i.e. your website) and where another organization controls encryption (i.e. their website/API). Make sure that your certificates are signed and that you don’t transmit PAN to an organization with an expired certificate. |
| Requirement 5 | Any systems not commonly affected by malware must have a defined periodic risk review. Malware scans must be defined by the organization based on risk. | Perform a risk assessment that can be based upon documented risks - not a knee jerk reaction. |
| Removable media must be reviewed for malware either automatically when attached to systems, or through analysis of those systems when removable media is attached. | Ensure your AV product can support scanning of removable media. | |
| Implement an automated mechanism for detecting and protecting personnel against phishing attacks. | Implement anti-spoofing controls through an email provider and link-scrubbers or anti-malware technology. | |
| Requirement 6 | Maintain an inventory of bespoke and custom software including third-party integrated components. | Utilize tools and/or manual processes to enumerate libraries. (something like Snyk should be able to help). |
| Implement an automated technical solution to detect and prevent web application attacks such as a web application firewall (WAF). Implement methods to determine all payment page scripts are authorized, maintaining integrity, and documented in a script inventory. | The integrity of scripts can be enforced by several different mechanisms including, but not limited to: sub-resource integrity (SRI), a CSP, and proprietary script or tag-management systems, which can prevent malicious script execution. A tool like SourceDefence can help with this. | |
| Requirement 7 | All user accounts and privileges need to be reviewed at least every six months to ensure access is granted based on job function. | Make sure to account for job transfers. Folks who are transferred who don’t need as much access commonly fall through these processes. |
| Application and system accounts must be managed based on least privilege and reviewed periodically based on risk. | Inventory non-user accounts, then ascertain guardrails in how these accounts should be used (limit admin permissions, restricting hours of use, ability to be used for remote access, etc.). | |
| Requirement 8 | Increased minimum password length from seven to 12 characters. | Use passwords with at least 12 characters. |
| If passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days or utilize zero trust (Service Providers only). | Analyze if you would like to rotate passwords or implement zero trust (i.e only allowing logon for various parameters, like geolocation, time of day, etc.). | |
| Implement MFA for all access into the cardholder data environment, not just non-console remote access. | The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function. | |
| Secure the implementation of the MFA system. | Make sure MFA can’t be bypassed and isn’t susceptible to replay attacks. | |
| Manage the use of system / application accounts with interactive login. | Try to disable interactive use of application accounts. If not, there will be five actions that need to be taken: time limited, business justification, approval, user identity is confirmed, and user attribution is tracked. | |
| Do not hard-code passwords/passphrases into files or scripts for any application / system accounts that can be used for interactive login. | Utilize code repository functions to detect accounts/passwords. | |
| Implement practices for protecting passwords for application and system accounts against misuse. | Prepare to rotate system passwords, and make sure their password/rotation mix makes sense. | |
| Requirement 9 | Perform periodic POI device inspections based on risk. | Define how often this review is to be performed. |
| Requirement 10 | Utilize automated mechanisms to perform audit log reviews. | Make sure any systems you were doing manual logs in can ship logs to your SIEM. |
| Implement controls to detect, alert, and address / respond to failures of critical security control systems (new for merchants). | Service providers have been doing this requirement — now merchants will need to. Figure out how you can detect when a security control fails (ie. who watches the watcher). | |
| Requirement 11 | Manage all non-critical and non-high-risk ranked vulnerabilities found during internal vulnerability scans. | Make sure you start focusing on medium/lower risk vulnerability churn. |
| Perform authenticated internal vulnerability scanning. | Make sure your vulnerability scanning tool can do authenticated scans. Inventory all targets to see if they can accept authenticated scans. Set up credentials, and manage credentials in accordance with requirements in section 8. | |
| Multi-tenant service providers must support their customers' need for external penetration testing. | Set up a contracts process to enable this requirement. | |
| Service providers need to implement intrusion-detection and or intrusion-prevention techniques to detect, alert on / prevent, and address covert malware communication channels. | See if your current IDS/IPS can detect covert malware communication channels. Select an IDS/IPS that can do this. | |
| Implement a change-and-tamper detection mechanism on payment pages to monitor and alert for unauthorized modifications. | Mechanisms include but are not limited to: the report-to or report-uri CSP directives can report violations of the Content Security Policy (CSP), Synthetic user monitoring can detect changes to JavaScript in payment pages and alert personnel, Embedded tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected, Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel. A tool like SourceDefence can help with this. | |
| Requirement 12 | Perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently the control is performed. | Each of these are documentation/process-related. Simply review the requirements and begin the documentation processes. Contact your Secureframe compliance manager or QSA to help answer questions. |
| Document and review cryptographic cipher suites and protocols in use at least once every 12 months. | ||
| Review hardware and software technologies in use annually. | ||
| Service providers must document and confirm PCI DSS scope at least every 6 months and upon significant change to the in-scope environment. | ||
| Review and update the security awareness program at least once every 12 months. Include threats, vulnerabilities, and acceptable use of end-user technologies in security awareness training. | ||
| Perform periodic incident response training based on risk. Implement an incident response process for detection of stored PAN anywhere it’s not expected. |
Wie Secureframe Ihnen helfen kann, die aktuellste Version von PCI DSS zu erfüllen
PCI DSS kann ein schwieriges Rahmenwerk sein, um es zu organisieren, zu verwalten und Jahr für Jahr einzuhalten. Hier kommt Secureframe ins Spiel.
Ihnen wird ein Compliance-Manager zugewiesen, der Ihnen jährlich bei der Abgrenzung Ihrer PCI DSS Umgebung hilft und sicherstellt, dass Sie verstehen, was Ihre Karteninhaber-Datenumgebung ist, welche Systeme verbunden sind und welche Netzwerke isoliert und außerhalb des Geltungsbereichs sind. Der Compliance-Manager passt den PCI DSS-Bericht an, um Ihren PCI DSS-Bereich widerzuspiegeln, damit Sie nur die für Sie geltenden Anforderungen sehen.
Das ganze Jahr über stehen Ihnen Secureframe-Compliance-Manager zur Verfügung, um Ihnen bei der Vorbereitung zu helfen und vor Ihrem Audit mit Ihnen eine Lückenbewertung durchzuführen, damit Sie sicher sein können, dass Sie die PCI DSS-Konformität vor der tatsächlichen Bewertung durch Ihren Prüfer erfüllen.
Verantwortliche und Zuständigkeiten für Kontrollen sind ein großes Hindernis in PCI DSS 4.0. Secureframe ermöglicht es Ihnen, Verantwortliche für Aufgaben, Kontrollen und Überprüfungen innerhalb der Plattform zuzuweisen, damit Sie diese Anforderungen erfüllen können.
Secureframe bietet auch Schulungen zur Sicherheitsbewusstseinsbildung und Schulungen für sicheres Codieren an, und wir überprüfen die Schulungen jährlich, um sicherzustellen, dass sie auf dem neuesten Stand sind. Sie können die Durchführung der Schulungen zur Sicherheitsbewusstseinsbildung und die Annahme von Richtlinien einschließlich der akzeptablen Nutzung innerhalb der Secureframe-Plattform verwalten.
Da Iterationen von Kontrollen jetzt risikobasiert sind, ermöglicht Ihnen Secureframe die Verwaltung der Intervalle für Tests basierend auf Ihren bewerteten Risiken. Wenn Sie monatlich Schwachstellen-Scans durchführen möchten, können Sie diesen Test monatlich auslösen lassen.
Wir haben auch vorab evaluierte Partner für alle Drittanbieter-Dienste, die Secureframe nicht durchführen kann. Wir haben ein Netzwerk von Penetrationstestern, ASV-Scan-Partnern sowie Prüfungspartnern, die Ihnen gerne bei der Erreichung der PCI DSS-Konformität helfen würden.
Um mehr darüber zu erfahren, wie Secureframe Ihnen helfen kann, PCI-Konformität zu erreichen und aufrechtzuerhalten, vereinbaren Sie eine Demo.