welcome to the cyber E d. Mystifying P. C. I. D. S s compliance course.
This module will focus on the goals of the PC idea sets and the requirements associated with them.
This video introduces you to a requirement eight.
We will talk about the requirements associating with how do you handle identity within the CD?
The learning objective of this video is to discuss some of the ends and outs of each of the mandates associated with the identity in the CD.
This section of the PC idea says compliance requirements is focused around how the merchant manages the identities or user accounts for administration and use of the CD.
These requirements don't extend to your customers who may be interacting with your environment to provide payment information
will explore how you should handle naming your accounts, policies associated with those accounts and the minimum password requirements, which I'll briefly talk how you should go above and beyond what PC I requires.
I do want to know early that requirements 8.1 dot one
eight dot to 8.0.338 dot to 0.6
do not apply to user accounts within a point of sales payment application that only has access to one card number at a time to facilitate a single transaction.
Essentially, these are accounts associated with cashier accounts and point of sale systems.
81 wants you to define an implement policies and procedures that ensure proper user identification management.
All right, so eight, not 1.1, is an easy one.
Everyone that operates in the CD should have their own account assigned to them.
There shouldn't be any shared user accounts.
If two or more people are using the same account, then it becomes increasingly difficult to attribute any action to a specific person.
If someone is using a shared account and delete some critical data, how are you able to figure out who actually did this action
To eliminate this risk? All users should have a unique I. D.
Again, the exception is the point of sale systems.
The auditor will be looking to validate that these accounts have very few privileges.
As a merchant, you must have tight controls around the creation and modification of user accounts.
An auditor will be looking to ensure that user accounts granted access to systems are all valid and recognized. Users
have strong processes must be put in place to manage all changes to user I. D. S and other authentication credentials,
the more detail you can provide around this process that better
for 813 and 814 The requirement states that you have to have processes around old and revoked accounts.
Stale accounts are frequently used as an attack vector.
You have to make sure that accounts associated with people who no longer work for your organization are disabled and then removed.
An auditor would do things like interview your human resource is personnel to get an understanding of how employees are on board it and what termination looks like.
It is often the case that third party service providers will be helping you maintain or deliver service is for your CD.
In order to facilitate this, you will need to be able to grant them access to your environment.
There have been many breaches in the news that were due to these types of service providers being breached and then using their networks to break into the network of the real target.
This requirement is around making sure you haven't placed some controls to prevent that from happening to you.
Make sure that at a minimum they have the minimum privileges and they're monitored closely.
Thes sets of requirements are the minimums.
Six. Failed log on attempt should lock out the user.
The lockout should be at least 30 minutes or unless it's manually reset by an admin.
And if a session has been idle for 15 minutes, the user needs to re authenticate
toe off. Indicate into CD systems. You have to have a password, a token or a biometric control.
Essentially, you can't just walk up to a system and access it without at least one of these things
again, accounts that are associative a point of sale systems are exempt
for requirement 8 to 1. You need to make sure that passwords are not stored or transmitted via clear text.
There needs to be strong cryptographic controls in place For both instances,
this means that protocols like Telenet should not be used or must have mitigating controls put in place because telnet transmit traffic and clear text over the network.
You should also take care tohave some networking equipment
because If you explicitly tell it to encrypt passwords of strong cryptography, it may be stored in the configuration. In the clear text,
the 8 to 2 requirements around password reset functions.
Someone should not be able to circumvent any of your controls and processes to force the reset of a password and potentially log and Impersonating another user.
For instance, if I call into your help desk and say hi, I'm Sam and I need a new password,
your health desk needs to be able to validate that. I am saying somehow
I commonly see problems for them itself in applications with poor logic around password reset functions.
Okay, so here's a list of what are commonly considered to be what you need to do to have a secure password policy.
Unfortunately, the research has proven that these requirements are actually ineffective, and Attackers can frequently abuse password with these minimums.
So I always recommend that merchants trying to go above and beyond these requirements
recommend password to be longer than seven characters,
and I recommend password should include special characters. In addition to numbers and characters,
the characters should consist of upper and lower case characters.
None of these are necessary to be compliant and are probably still the mandate to support legacy applications.
But if you want to be more secure instead of just compliant than revisit your password policy,
this requirement grouping is around the utilization of multi factor authentication into the CD.
So some merchants struggle with this requirement.
In all instances of access in the CD remotely for administrative function, the merchant must use multi factor authentication.
So this means two out of the three things we mentioned earlier with something you know, something you have and something you are.
There are numerous ways to meet this requirement, so I don't really want to dive too deep into the potential solutions. But I will note that your authentication mechanisms need to be separate and independent of each other.
There needs to be a physical separation so that access toe one factor does not great access to another.
And if one factor is compromised, it does not affect the integrity and confidentiality of the other factor.
Missile crime and extends on multi factor authentications, all users that access a CD from untrusted networks or the Internet,
like with all other requirements, all of the policies and procedures need to be documented and disseminated.
You need to provide to your end users basic instructions on how to manage your user accounts and how they should be protected.
A lot of times, this is embedded in the on boarding documentation or in regular security trainings.
The 85 grouping is around the handling of shared and generic user accounts.
As you mentioned before, just don't you shared accounts exempting point of sale systems.
Examples of generic accounts are the guests and administrator user accounts in window systems.
These generic accounts need to be disabled or renamed so that an attacker can't just attack known accounts that are often generally less secure.
Requirement 851 is for service providers.
The mandate is that they do not share credentials with each customer they support.
In the event that one of these credentials is compromised, the attacker cannot pivot to the entire customer base of the service provider,
so the 86 requirement is a bit of a restatement of the previous requirements.
If you're using multi factor authentications,
you just need to make sure no one else can leverage that second factor for authentication.
For example, if you're using a token that is auto generated. That same token can't be shared by two separate administrators.
The 87 requirement is around database access
and users or not to have direct access to the database.
Any data that they need for their job function needs to be collected via another front end application.
No queries or any other interaction is allowed on the database itself.
This access is only allowed for database administrators.
The final requirement for this group is document document document.
All of your policies and procedures need to be put in writing and deliver to all that are impacted.
That summary. We discussed all of the mandates associated with PC I. Requirement eight.
Requirement eight is all about the handling of identities and accounts. Within your CD,
you need to incorporate multi factor authentication and tracked the potential for account abuse throughout your environment.
This includes regular users, administrators and service providers,
and now, for a quick quiz.
Inactive user accounts need to be removed within 30 days.
Inactive user accounts need to be removed within 90 days
when accessing the CD from untrusted networks, the user must a provide a user name and password.
BU shared admin credentials. See use multi factor authentication
or D use a service account.
Multi factor authentication of is required whenever accessing the CD from an untrusted network.
Users cannot submit passwords that are the same as any of the previous
A three passwords. Be two passwords
C four passwords, D five passwords.
The previous four passwords all have to be unique as defined by the PC, Idea says.