[Autogenerated] now, having have that hard think Andi,
Maybe posting questions to management that we probably need to
come back to the next phase of the compliance journey is to
understand what the current picture of payment card data
processing is within the organization.
The aim is to get a clear picture as possible of
where cardholder data is stored, processed and transmitted in the organization.
And, more importantly, why is being stored, processed or transmitted?
It's very rather,
an organization can give this clear picture without some
serious business and technical analysis.
What we need to do then is document what I call the cardholder data footprint,
describing where the cardholder data is stored,
processed and transmitted.
So we need to understand what systems it's on.
What networks it's transmitted over on what applications touch cardholder data.
To do this successfully requires two parallel streams of work.
The first maps of business processes on the second uses technical tools to
discover where cardholder data is present within an organisation.
Systems.
Let's start with mapping business processes,
and that means we need to understand our acceptance channels.
If we have face to face retail environments,
how do we process cards do we have any e commerce websites,
and if so, how did they process cards?
And finally,
do we have any mail order or telephone or the capabilities on a
word of advice here that you often find an organization does
have a telephone order capability, even though it doesn't advertise it.
He might be through the retail stores directly.
Or there's a small team somewhere in customer
service that you never knew existed.
That takes telephone orders for special people.
Having identified the acceptance channels that exist within an organization,
there are three key questions you need to find the answers for.
Firstly, where does the date ago?
What applications, systems and network store process or transmit cardholder data?
Secondly, what volume is there?
How many transactions?
A day of processed?
It's cut.
All the data is stored.
How long has it kept for what data is stored?
Why's it stored?
And then, finally, who owns this business process?
Because if you want to change the business process,
say to remove cardholder data storage, who will need to agree to this?
And you'll remember from the first module that there
are a number of different functions.
Associate with Kartal, the data processing.
These are authorization clearing settlements on undoing transactions.
In each of these functions,
some cardholder data will be processed apart from settlement.
And so when I mapping where carnal the day through,
stored, processed or transmitted a map each one separately,
for example, I go to the retail channel and,
firstly, map out hone authorization happens.
Then separately,
I describe the process of sending clearing records at the end of the
day because different systems may be involved.
So for each acceptance channel,
you need to map out which systems store process transmit Kartal the
data for all of the appropriate payment of functions.
So,
for an example of mapping the payment flow of
cardholder data in an organization,
you might remember the retail network of the wired brain
coffee company we met in the big picture cause it's a typical
face to face retail environment.
And here we've got a payment terminal on the point of sale system Ah,
local server within the store which contacts the bank for authorization,
some sort of connection through to head office,
where there's a payment processing system which talked to
the bank for clearing and then a database server that keeps
a record of all transactions.
No, again, taking this is an example.
Let's take Take this system and catalogue where Kartal the data is stored,
processed or transmitted.
The payment terminal processes and transmits cardholder data,
as does the point of sale system and in my experience is
pretty typical for the point of sale.
System will also store card hold the data,
even though it probably doesn't need to the store
server processes and transmit Stater.
And again, in my experience, working in retail environments,
it probably stores as well for a just in case the acquirer is off line.
Anytime.
Reason.
The cardholder data is transmitted through the firewall to the bank and
then also through the connection to head office into the fire or head
office and then onto the payment system that will process and transmit
the carnal the data as well.
I guess it males the story we have to look to find out.
And finally, the database server definitely does store cardholder data.
Now, looking at the White Break Coffee e commerce system,
we ever use a shopping on her computer at home,
a connection through to the Merchants Web server located within in DMC,
the Payment Processing System,
which talked to the bank for authorization and clearing,
and finally, that database server that keeps a record of all transactions.
And again, if we catalogue where cardholder data is stored,
processed or transmitted,
we start off with cardholder data transmitted from the user's browser
through the perimeter firewall and onto the Web server,
where it be processed.
In transmitted onwards,
you'll often find that badly configured Web service also
store cardholder data in case payment processing systems are
unavailable from the Web server.
The card Tetris was transmitted through the D M Z
firewall to the payment system, where it's processed and transmitted to the bank.
And, of course, the payment system may well store a copy of the cardholder data.
And then, finally,
the cardholder data is stored on the database server in
parallel to the business process.
Analysis on organization should also use technical tools to
look for cardholder data stored in IT systems.
Persistently called data discovery,
the organization needs to select a data discovery tool designed to
find cardholder data on there are lots available.
They will search through every system and discover where
cardholder data is stored in databases in flat files on
every single server and workstation,
the organization on every website the organization has on in every log
file that's being produced and saved by the organization.
And this needs to be done across the entire organization,
in production systems, in test systems and development systems.
In staging systems, you have to look everywhere on every single system.
And if you've never done this exercise before,
you'll find cardholder data in places you just did not expect.
Backups that people took before they did a system upgrade
testing development systems that belong to no one systems
that people stopped using years ago.
But they have never been decommissioned.
And as you come across cardholder data that you don't need,
you should delete it because this will instantly reduce the amount of
card old ization that could be stolen by an attacker.
And that's a good thing.
The other major business discovery exercise you need to do is to
work out who else has your cardholder data.
So here we're looking for what PC idea says calls service providers.
Third parties that store process transmit cardholder data for you or third
parties that you outsource business processes or facilities or technology to
who could affect the security of your cardholder.
Data on a really good thing to discover when you talk to third parties is what
other services they can provide to help you comply with PC,
Idea says.
If they're in the business off doing things with cardholder data,
they most developed technical solutions to outsource
other payment processing activities,
which could help you reduce the footprint of card all
the data within your organization.
So understanding what's possible from supplies is really helpful
when you're going through your scoping decisions.
Once you've been through this exercise for every
acceptance channel and every business process,
and you've used a technology solution to discover where
carnal the data is in your organization,
you have an accurate picture of all the systems,
networks and applications that store process or transmit cardholder data.
Whether that's just the primary account number were also any
sensitive authentication data such as the CVC to code this
using e commerce transactions as well as understand the
technical flow of card all the data.
You should have a good view of the underlying business processes and also
know who within your organization is responsible those business processes
because you'll need to work with those people.
If you want to change things on.
The final part of the picture is that you'll know about
all the third parties who store process.
Transmit Kutteles of data for you and also way you outsource business.
Process off all facilities to service providers that could affect the
security of the cardholder data you're responsible for in the next module
will take a good hard look at this picture.
The safe that describes the environment.
We want to make PC idea says compliance.
Or, if you want to change some business processes old or at some technology,
will change technology to make the compliance job much easier on.
Remember, that's about ongoing compliance as much as anything else.
But before that, let's join the conversation I had with Q.
S.
A.
Jacob Ansari, where we discuss how you can use a cure,
say,
to help all the way through the compliance journey and also the
different roles that cure saves can fulfill