So, let's start to look at the PCI standards with the most famous,
and the one we've all probably heard about,
the Data Security Standard, or PCI DSS.
It is a general information security standard with an emphasis on card data.
And I know it has had its critics, but believe me,
in 2006 this was an advanced data protection standard.
It contains logical and physical controls,
and applies to all organizations that store,
process or transmit cardholder data, including merchants,
acquirers, and issuers, and third parties that provide services to merchants,
acquirers, and issuers,
who in PCI terms are called third‑party service providers or TPSPs.
The PCI DSS standard consists of about 300 logical and physical
security requirements that covers 6 main areas.
Firstly, building and maintaining secure networks,
which contains requirements for installing and managing firewalls,
along with system hardening and the removal of default passwords,
default services, and default security parameters.
Second, a requirement to protect cardholder data,
typically by encryption,
both in transit and when cardholder data is stored at rest.
Third, are an extensive set of requirements to develop software securely,
to patch and maintain developed and bought software,
applications, and operating systems.
Also, a requirement to run effective antivirus or antimalware software.
Next are requirements that control the logical and
physical access to cardholder data, including privileged access control,
the use of IDs, passwords, and multi‑factor authentication.
Fifth are requirements to have extensive logging and
monitoring of the logs combined with vulnerability scanning
and a penetration testing schedule.
And finally,
all this needs to be documented and understood by everyone in an organization
that has responsibility for the protection of cardholder data.
In all, PCI DSS contains those requirements across six high‑level areas.
The requirements apply to all systems, people,
and processes that store, process or transmit cardholder data,
and also systems that are connected to or could affect the
security of cardholder data in the environment.
Next, PCI DSS's best friend, which is the Secure Software Standard.
This is a new standard.
It was released in 2019, and replaced a very old standard,
the Payment Application Data Security Standard,
or PA‑DSS.
The Secure Software Standard is a software development standard designed
for vendors that produce commercial payment software.
The standard aims to ensure that software developed to it
protects the integrity and confidentiality of payment
transactions and associated data.
One of the core benefits is that if a merchant buys payment software
that's been developed to the Secure Software Standard,
they will find it much easier to meet the requirements of PCI DSS.
For example,
one of the PCI DSS requirements is that passwords have to be over a
certain length and use a combination of characters.
A Secure Software Standard validated application would allow passwords of
that length and with the complexity that PCI DSS demands.
The Secure Software Standard is intended to be modular,
and although at the time I made this course there is only one
module that applies to any application that stores,
processes or transmits payment card data,
other modules are planned.
So let's look at where PCI DSS and the Secure
Software Standard apply in practice.
Now you might remember this picture.
It shows how payment card data may move around a
face‑to‑face retail environment.
Which of the PCI standards apply here?
Well, Wired Brain Coffee stores, processes,
and transmits cardholder data, so as an organization,
it will have to protect that cardholder data by
adhering to the requirements of PCI DSS.
There's quite a subtle distinction here.
It's the organization as a whole that has to comply with PCI DSS.
It's not a component, a server or some software,
it's the whole company which has to ensure that any systems,
processes or people that store,
process or transmit cardholder data meet the PCI DSS requirements.
And if we take our E‑commerce example,
PCI DSS applies to the way that Wired Brain Coffee secures the
cardholder data it receives from cardholders.
And, again,
it's the organization that has to make sure that all its
systems that can affect the security of cardholder data
meet the PCI DSS requirements.
The Secure Software Standard is a standard for companies that
write software applications which are sold to merchants and to
third‑party service providers, and allows the company to say that their software,
if implemented correctly,
will secure cardholder data and will allow an organization to
comply with the requirements of PCI DSS.
It's really important to understand that just by buying software
that's been validated to the Secure Software Standard,
it doesn't mean that the merchant who has bought that software
automatically becomes compliant with PCI DSS.
It's certainly going to help,
but there are all the other requirements in PCI DSS,
such as networking, antivirus, physical protection,
logging, monitoring, testing, documentation,
that the merchant also has to put into place.
PCI DSS does not require a merchant to use Secure
Software Standard validated software, but as I said earlier,
it will help the merchant become compliant with PCI DSS.
However,
some of the card schemes do require that merchants only use
Secure Software Standard validated applications.
In this face‑to‑face retail example,
any of the payment software used to process a payment on its
way to authorization could have been built to comply with
the Secure Software Standard, and in an E‑com environment,
Wired Brain Coffee could have bought a shopping cart or
back end payment system off the shelf,
and so this software could also have been validated to comply
with the Secure Software Standard requirements.
The Secure Software Standard is actually one of two
standards in the Secure Software Framework.
The other is the Secure Software Lifecycle, or Secure SLC Standard,
that's designed to help payment software vendors design,
develop, and maintain secure payment software through the software lifecycle.
It requires vendors to manage security through the
development process and after release.
Although both standards in the Secure Software Framework are
designed for companies that make commercial software,
they are really good standards to follow for any organization
building payment software for its own use.