Fundamentals of PCI-DSS

Learn everything about the Payment Card Industry Data Security Standards, including assessment and the 12 requirements.

What you'll learn
Terminology essential to the PCI-DSS, such as CDE, CHD, SAD, PANs, SAQs, ROCs, QSAs, as well as other payment industry terms such as issuing and acquiring banks
A brief history of the PCI-DSS and its major revisions
How the assessment process works, with ROCs and SAQs, and a clarification of the 8 types of SAQs
Everything about Requirement 1, involving having a firewall configuration to isolate your card data, network documentation and more
Everything about Requirement 2, including changing vendor defaults, isolating server functionality and securing vulnerabilities in devices
Everything about Requirement 3 in terms of securing stored data, including encryption protocols, key lifecycle, key management and more
Everything about Requirement 4, protecting data in transit, including masking plaintext PANs and using strong encryption protocols such as WPA/WPA2
Everything about Requirement 5, in terms of preventing malware through an antivirus solution that is frequently updated and frequently runs scans
Everything about Requirement 6, in terms of developing securely, doing regular vulnerability assessment and patching, as well as including developer protections
Everything about Requirement 7, in terms of limiting access to card data by "need-to-know", minimising who accesses it formally through an access control system
Everything about Requirement 8, in terms of identifying access through unique user IDs, strong authentication and MFA, password practices and more
Everything about Requirement 9, in terms of physical security, visitor identification and authorisation, as well as physical media storage/transport/destruction
Everything about Requirement 10, in terms of having a logging solution, logging specific required events, specific data points, and maintaining log integrity
Everything about Requirement 11, in terms of doing regular AP (authorised + rogue) and IP audits, vulnerability testing, pentesting, as well as having IDS/IPS
Everything about Requirement 12, in terms of having a company-wide InfoSec policy, including employee screening, third-party screening, technology uses and more

Description
SECURE YOUR DATA, SECURE YOUR KNOWLEDGE

Payment fraud has risen over time, and unfortunately is not slowing down.

The PCI-DSS, or Payment Card Industry Data Security Standards, are a set of strict standards for any organisation dealing with card data.

They tell you how to store and transmit these data.

However, it's hard to explain a course that both covers the technical knowledge, but also practical applications and examples.

In short, most PCI-DSS courses are either only about the tech, or about the business.

If only there were a course that combined both…

Well… that's what this course aims to change.

LET ME TELL YOU… EVERYTHING

Some people - including me - love to know what they're getting in a package.

And by this, I mean, EVERYTHING that is in the package.

So, here is a list of everything that this course covers:

A clarification of all terms used in the PCI-DSS, including what is the CDE, what is CHD, SAD, whether an organisation must take an ROC or SAQ, as well as some "general" payment industry terms such as what is an issuing bank and an acquiring bank;

The history of the PCI-DSS since 2004, with several iterations and its own release lifecycle;

The merchant assessment process, based on their classification from Level 1-4, and how both SAQs and ROCs work, as well as the 8 different types of SAQs, and the types of machines/merchants they target, including the SAQ-A and SAQ-A-EP, the SAQ-B and SAQ-B-IP, the SAQ-C and SAQ-C-VT, the SAQ-P2PE-HW, and finally, the most general SAQ-D;

The anatomy of a payment process, involving a cardholder and a merchant, from authorisation to authentication, clearing and settlement, and the role of the issuing bak, the acquiring bank and the card company;

An overview of all 12 PCI-DSS requirements, as well as their relationship with the 6 goals;

A deep dive into Requirement 1 (Have a Firewall), including firewall configurations and standards, documentation on network topology and card data flows, setting up a DMZ, rejecting unsecured traffic, and more;

A deep dive into Requirement 2 (No Defaults), about removing default passwords/accounts/strings from devices, but also isolating server functionality and removing unnecessary ports/services/apps that may present vulnerabilities;

A deep dive into Requirement 3 (Protect Stored Data), about using strong encryption to protect cardholder data, as well as having proper data retention policies, data purging, as well as masking plaintext PANs, not storing SAD, and using proper key management and key lifecycle procedures;

A deep dive into Requirement 4 (Protect Transmitted Data), about using strong encryption when transmitting CHD across public networks such as cellular or satellite, as well as masking plaintext PANs in transit, especially across IM channels;

A deep dive into Requirement 5 (Prevent Malware), about having an antivirus solution on all commonly affected computers in order to prevent malware, as well as access control policies to prevent disabling AV software;

A deep dive into Requirement 6 (Develop Securely), about doing vulnerability ranking and timely patch installation for both internal and 3rd-party applications, as well as including security requirements in the SDLC, as well as training developers to protect against common exploits such as code injections, buffer overflows and many others;

A deep dive into Requirement 7 (Need-to-Know Access), about limiting access to CHD by personnel as much as possible, defining permissions by role, and having a formal mechanism for access control to consolidate this, such as LDAP, AD or ACLs;

A deep dive into Requirement 8 (Identify Access), about tying each action to a unique user, including forcing unique IDs, automatic logouts on inactivity, lockouts on wrong password attempts, removing inactive accounts, limiting third-party access, forbidding the use of shared IDs, forcing physical security measures to be used only by the intended user, and more;

A deep dive into Requirement 9 (Restrict Physical Access), about authorising and distinguishing visitors, enforcing access control to rooms with CHD, as well as the proper transport, storage and disposal of physical media containing CHD, with different sensitivity levels;

A deep dive into Requirement 10 (Monitor Networks), about logging. Having a logging solution that is operating, logging specific events (such as all failed operations, all admin operations, all operations on CHD, etc), logging specific elements in each event (such as the user ID, the operation status, the affected resource, etc), as well as having a single time synchronisation mechanism for all logs, FIM (File Integrity Monitoring) on logs, frequent log review and proper log retention;

A deep dive into Requirement 11 (Test Regularly), about performing regular scans for Access Points (APs), both authorised and non-authorised ones, as well as regular vulnerability scanning and regular penetration testing (from inside and outside, and multiple layers), as well as having FIM (File Integrity Monitoring) on all critical files, as well as having an IDS/IPS (Intrusion Detection/Prevention System) to prevent attacks;

A deep dive into Requirement 12 (Have an InfoSec Policy), which covers roles, responsibilities and owners at levels of the organisation, including varied topics such as technology usage policies, employee screening, employee awareness, third-party selection criteria, regular risk and vulnerability assessments, among others;

A review of all 12 requirements and general patterns among them, such as "denying everything" by default, using common sense for certain parameters, enforcing change management on all changes, and always prioritising security (both logical and physical);

MY INVITATION TO YOU

Remember that you always have a 30-day money-back guarantee, so there is no risk for you.

Also, I suggest you make use of the free preview videos to make sure the course really is a fit. I don't want you to waste your money.

If you think this course is a fit and can take your fraud prevention knowledge to the next level… it would be a pleasure to have you as a student.

See on the other side!

Who this course is for:
Any payment professional looking to know more about information security of card data
Any InfoSec professional looking to know more about the information security requirements of the PCI-DSS
Any payment professional that wants to better protect card data in their systems