[Autogenerated] the final network firewall requirement requirement,
or 1.3 wants to make sure that there's no way from the
Internet to your cardholder data environments.
The requirement is simply written that direct connections
between the Internet and systems within the cardholder data
environment must be prohibited.
No, silly, says Direct connection.
So this doesn't mean that you can't have inbound traffic from
the Internet talking to the cardholder data environment
because that would break you know, every single e commerce website in the world.
It simply means that any connection from the
Internet to a device within the CD A,
like a Web server must pass through something that preferably terminates
but certainly always manages the direct I p connection,
such as the firewall that the whole of Requirement one is about.
Look in very basic terms,
This requirement says you have to use your firewall
on route all traffic through it.
To test this requirement,
the JK USA will look a firewall on router configurations.
I like guests.
They'll also look at your network diagram and your card.
Hold the data flow diagram so I can understand what's going on.
The first sub requirement,
1.3 point one wants to make sure that any device or system,
which is intended to be publicly accessible,
is placed in the D.
M Z on again.
The standard is really came here to reinforce that inbound traffic from the
Internet to the systems work for expecting it must be authorized it and the
authorization must be at the host poor service level.
For example,
you have an authorization that says we allow inbound traffic on
ports 80 on Port 443 from the Internet to the Web server for the
purpose off people browsing our website and establishing tear
less connections to it.
We can see this illustrated in our sample network,
where you can see there We've got a Web server sitting in D m Z.
In terms of the testing procedure,
the standard says that the JK USA will look at firewalled router configurations,
but again, but also gonna be looking for those records off,
particularly traffic being authorized on that network diagram again.
Requirement 1.3 point two seems a bit obsolete because it may be says that
inbound traffic has to stop in the d m Z that you created for it.
So for the avoidance of doubt.
The standard doesn't allow you to eternal traffic from the public
Internet into your internal network through the D M Z.
In other words, if you want a system to provide publicly accessible,
service is the only place your brother is in your D m Z on.
To test this.
The cure so is going to look at your firewall configurations,
and that's going to be the configuration of two firewalls,
but one that protects the D M Z from the Internet and the one between the D.
M Z on your internal network requirement.
1.3 point three wants to make sure that your firewall protects you
from spoofed packets originating from the Internet.
And it is probably harder not to comply with this requirement that is
to comply with it because most firewalls will do.
This is a matter of course.
It would have to find a way of turning it off.
The exact requirement is that anything with a forged source i p address
appearing on the external interface of the firewall is dropped.
A common attack many years ago was disproved.
The internal I P addresses onto the external interface of the firewall to
confuse the fire war so it would pass your traffic ______.
This is what this requirement theoretically protects against,
but practically every fire world will do this out of the box.
Now, in terms of testing this requirement,
the JK USA is just going to look at the firewall configuration requirement.
1.3 point four is concerned with traffic leaving
the cardholder data environment, not traffic coming into it.
It reinforces that policy requirement in requirement 1.2 point one about
only allowing necessary and authorized traffic out the CD on prohibiting
unauthorized traffic from leaving the CD.
Eight.
The Cure say,
will look at the firewall configurations matches with your documentation,
saying what traffic should be allowed out.
The CD on has been authorized by management's.
Just as with requirement 1.1 point three.
It's really hard not to comply with Requirement 1.3 point five,
which is to use state ful firewalls, state full firewalls,
keep track of the network conversations and prevent external
systems talking to internal systems which are not themselves
intended to be publicly accessible.
State.
Full firewalls maintain the state of every conversation
passing through the firewall I mean, that's where they get their name from.
They prohibit connections that are not in a concert with the state.
So, for example,
if something on the internal network has started a conversation with
something on the external network on the Internet,
the father was waiting for a reply to that conversation.
But it wouldn't let a brand new inbound conversation talk
to that thing on the inside Network.
Now it's gonna be almost impossible to find a fire war now,
which doesn't operate in the state for manner.
When the standard was written, that wasn't always the case.
The Q s.
A.
Is going to look at the firewall configuration particularly diligent.
JK USA may try to initiate a prohibited connection from the Internet,
so it will go to the external interface of the firewall to
validate that such connections are prohibited.
Requirement 1.3 point six is a really sensible one.
When you think about it simply, P.
C.
I d.
Assess the ______ from storing cardholder data within of DMC.
You know,
I know you'd agree with me that placing stores have cardholder data
in the same network zone where you have publicly accessible systems
to the Internet is a pretty bad idea.
So the requirements to ensure that any system components which store
cardholder data are placed in an internal zone.
We're going to look at the rules about protecting stored cardholder data on how
it needs to be encrypted when we get to Requirement three.
But this requirement just says, If you're storing it,
don't put it in your D m Z.
I also want to quickly clarify what store means,
because some Q essays can get over excited about this
requirement in this context storming,
saving things on death I don't care whether it's around desk or
a physical disc or a virtual disc or a storage area network or
any other sort of storage media.
He means you're intentionally or the system is
intentionally saving the cardholder data.
It doesn't mean something like the Web servers decided
temporary to store some data around.
It doesn't mean temporary storage in Ram while
while something's being processed,
you could see this clarification the guy's nose.
But there were some que ser que essays who got a bit well excited about this.
So if you look at our sample network,
you can see we've got a web service sitting in a d m Z,
whereas our database server, which we assume in our sample network,
is going to store card.
All the data is sitting in the internal zone,
protected from the d m Z by a firewall test requirement 1.3 point six.
The standard says the cure say is going to look a
firewall on router configurations.
However, if I was York USA,
I'd also to see your network and cartel the data flow
diagrams because they will tell me where the cut all the
data is still in the organization.
And I can make sure that you're not planning on
storing it in your DMC requirement.
1.3 point seven is another one of those.
It feels a little historic.
It wants you to keep your internal I p addresses
secret from anyone else in the world.
Now, Now,
this requirement isn't just a prohibition on Princeton's sharing on network
diagram with anything other than internal resources and your qs,
eh?
In fact, it doesn't explicitly mention the network diagram,
although actually that is implied in the requirement.
The core thing is is that your implements some technical measures to hide
your internal I p addresses from the Internet on again.
It's really hard not to do this now.
It's rare that people route their full internal I p
address range onto the Internet.
Mostly that's because people use network address translation or Matt or ported,
rest, insulation or pat on their firewalls s so that the internal,
like P Rangers never go on to the external network.
All people using non reachable ranges in terms such just 10 or 1 70.16
or 1 90 that once excite on their internal networks.
If you do use fully Ruta ble, I signed I p addresses on your internal network,
then you shouldn't let those pop out to the outside.
You should.
You should use network address translation to test this.
The cure so is going to do three things.
They're going to thirsty.
Look at the fire one on route configurations.
Secondly,
at the documentation that says how you intend to
accomplish this requirement and then finally,
they will speak with management on dhe.
I guess the network administrators to make sure, is a process to be followed.
If you actually did want to disclose your i P addresses
and how that would be authorized.
So if you don't actually want to show a network diagram with internal
I P address ranges to a supplier or to a Q S A.
We're not going to join a conversation I had with Jacob.
And sorry about the three PC ideas s requirements.
Jack is one of the most experienced que essays in the world.
We talk about what can go wrong when implementing these requirements,
how they could be misinterpreted on def.
The lack of compliance with any requirements typically lead to data breaches.
We also talk about what JK USA is looking for when
they come on sites undertaken, assessment,
the requirements themselves,
the theory and the rules of PC Idea says this conversation with Jacob is
intended to give you the practical insights into how to implement things
in the organization to meet the requirements.
How to prepare for an assessment on what a Q s A
really does when they come on site