[Autogenerated] requirement nine is very different from all the other PC
IDE CSS requirements because it deals with the physical protection of
cardholder data in both digital on the analog forms.
It's quite a long requirement because there are lots of
different areas associated with physical security,
and the areas covered include physical controls for
environments where cardholder data is stored,
process still transmitted and how to manage visitors in those environments.
How to look at the physical media that contains cardholder
data and that includes removable disks, tapes if anyone still uses them,
and paper with cardholder data written or printed on it on when that's being
finished with how to destroy physical media and paper.
The last part.
Requirement nine is concerned with the protection of
physical card reading devices on,
along with the mandatory requirements that deal with policies and procedures on
will cover these two last requirements in the next module.
Looking at the scope for this requirement,
it's everywhere that cardholder data is stored,
processed or transmitted,
but with one exception on that's because some of the
physical security requirements don't apply to areas such as
the public areas of retail premises.
So in our example network here.
The area where the point of sale system is physically located isn't
covered for things like physical access control,
but the store server,
which will be typically in the back office where the
public are not expected to be.
It is in scope of the requirements in the description of Requirement nine,
which is at the beginning of the requirement,
There are a couple of definitions.
It's really useful to be aware off.
The first is on site personnel on my yardstick for this is
typically anyone where there's a contractual chain between
the organization and the person, so this generally includes employees,
contractors and consultants.
The second is visitors,
which can think of as anyone in the environment who is not on site
personnel or who were not shoppers In a retail environment,
you're QoS is usually a visitor on not recognizing this.
Such could be an easy way to start your annual assessment off on the wrong foot.
Finally, media,
which is the definition site YSL paper and electronic
media but contains cardholder data.
And actually there's another definition that's not the start
is hidden in requirement 9.1 point one, which we need to know about,
because when we talk about restricting physical access,
the standard talks about sensitive areas,
which means anywhere that cardholder data is stored,
processed or transmitted.
Except those retail environments,
whether the cashier on a point of sale terminal,
because that's not a sensitive area.
Now, with those definitions to hand,
let's jump into PC IDE SZ physical security requirements starting off,
then with requirement 9.1,
which is to restrict physical access to systems in the
cardholder data environment to authorized people.
This is about physical access control, such as locks,
doors that require a bad reader or remain a key to gain
access to the cardholder data environment.
There's also a second requirement that sort of hidden in the guidance.
No testing procedure, which is the all console screens,
should be locked,
but actually this is generally already being covered in
requirement 8.1 point eight about screens.
Admin screens that are left unattended should be it should be timed out.
So to test this requirement,
the QoS is going to observe the physical access controls into the C D,
and also that consoles error locked by default.
The first sub requirement of 9.1 demands that
physical access needs to be recorded, monitored and logged.
So there's a record of who is physically bean in the 500 at any time.
On this is generally accomplished in a couple of ways.
The first is to make sure there are video cameras
covering the access points into the 500.
So typically these error going to be pointed at gates or doors.
Or secondly,
there's a system which records when a particular access card or a biometric is
used to the access control system can say who went to the C.
D E and when they entered it.
These records need to be kept for three months unless local laws prevent this,
which is an important general point.
You see that PC ideas has always comes behind and is subservient to other laws,
and organization is subject to you.
Confirm.
Find the reference to this rule in the first few pages,
the CSS, into the bottom of page five.
Now there are restrictions on how long access control logs and video
recorders could be stored in many European countries,
and in a dispute between what the law says on what PC
IDE CSS demands the law always wins, which is important to remind the QoS A.
Because there's there is a special box on their reporting form to
indicate the control is subject to local laws and regulations that
override PC IDE CSS and is good to remind them of because they don't
often have to take this box.
The testing procedure for this requirement is threefold,
firstly, that there are video cameras or logged access control mechanisms.
Secondly, that they're protected from tampering.
And thirdly, the data is stored for at least three months,
So the QoS Azure is going to test all of those elements.
Now I need to offer some words of warning about these
physical access control requirements.
Because I met super annoying QoS is who get really into this
one and make a meal of the assessment.
The guidance note clearly talks about making sure the camera and
access control logs should be protected from tampering.
In fact, let's just take a quick look at what the standard says,
so video cameras could be placed out of reach.
There could be monitored as good access control systems,
which could also maybe have some physical protection.
What's important here is what the standard doesn't say.
It doesn't say that these systems error in scope of
the PC IDE CSS requirements on.
Believe me, if that was the intention, the standard would say it.
They could be in scope if they were physically or
logically connected to the seedy, But that's not given now.
I always want to make sure that some documented controls for these
systems to prevent tampering there should be patched on.
Most importantly,
they need to be synchronized to the same time source of the rest of the network.
Because, believe me,
there's nothing more annoying in an investigation than a video camera on
access control system that still thinks it's 1990.
The next of requirement 9.1 point two is straight
out of the Kevin Mitnick playbook.
On it is concerned about Attackers physically connecting themselves
to the CD by plugging a cable into a publicly accessible network port
on the requirement is to disable them, not disable the Attackers,
disable the network ports,
which you could do by making sure they're not connected at
the patch panel or more normally now,
by implementing some sort of network access control or neck,
such as eight or 2.1 x,
which prevents a non authorized computer connecting to the network.
The Standard also says that ensuring visitors error always escorted by on site
personnel who prevent the visitor from plugging into the entities network would
meet the requirements because here it's really important to note the definition
of publicly means anywhere that members,
the public or visitors have access to on.
To test this,
the QoS A is going to look for publicly accessible network
ports and ask how access is restricted.
The testing procedure doesn't require them to try to plug their
laptop into every publicly accessible port.
However,
you need to make sure that if your control here is to always ______
visitors on your QoS A is treated as a visitor,
which they usually are.
Then you always ______ the QoS A never let them out of their
sight on watch out if they're going to try and plug
something in the last of requirement.
Concerned with physical access is about the security of networking
devices and physical cables basically anywhere a criminal contempt
URL with or intercept communications,
and I know that is more on more infrastructure moves to the cloud,
there'll be less places an organization has that fall into this requirement.
But whatever.
If you have users processing payments in retail
stores or telephone contact senses,
you still need to think about this requirement to restrict
physical access to network equipment, wireless access,
points of communication lines.
So typically that means putting things like access points
high up and out of reach and securing calms and
networking cabinets with locks and, if you particularly cautious,
even tamper evident seals.
To test this requirement,
the QoS is going to look at the physical access to
networking devices to the coms,
cabinets and cables and make sure the access is restricted to authorized people,
although it doesn't say in the standard most QoS error going
to be looking for supporting policy that says who should have
access to this type of equipment?