3.13 Requirement 10

00:00

welcome to the cyber ery demystifying P. C. I. D. S s compliance course.

00:06

This model focused on the goals of the P C I. D ss and the requirements associate it with them.

00:13

This video introduces you to requirement 10.

00:16

We will talk about the requirements and nuances associated with how do you handle the monitoring of access to re sources within the CD?

00:26

The learning objective of this video is to discuss how to monitor your CD E to determine if a potential breach is occurring or has occurred.

00:37

Were karma tennis all about tracking access in your environment?

00:41

You need to be able to tell who is doing what in your environment to facilitate any forensic activity that may be needed to take place in the event of a breach,

00:50

you need to be able to see what individuals are doing, what to which systems and how to protect your audit trails so that an adversary is not able to cover their tracks after an attack.

01:03

This all begins with requirement 10 1

01:06

As a merchant, you need tohave in place, audit trails that are tied to each user.

01:11

If an account is accessing a system, it needs to be locked.

01:17

The 10 2 requirements note all of the activities that need to be on it.

01:22

It's not just the failures but also the successful access of information.

01:26

So open account access is cardholder data. You should be able to know about it.

01:30

Have access. Attempts fail. You should be able to know about it.

01:34

If new processes or system level objects are created,

01:38

you should be able to know about it.

01:42

The 10 3 Requirement Group tells you all of the information that needs to be tracked in your audit logs.

01:48

Most current operating systems are able to support collecting this information natively and shouldn't be difficult required A requirement to me.

01:57

You just need to remember to collect all of these items when it comes to applications you are developing in house as well.

02:07

Time is a key component of auditing.

02:08

If you need to develop a timeline of activities users are engaged in over long periods or across systems, it will be difficult to develop a narrative of what happened if time sources don't match or could be tampered with.

02:22

So it's important that critical systems have their time sync to buy an authoritative source

02:28

for an industry accepted time source. There's a lot of ambiguity there and industry, except that can change.

02:35

I typically suggest time sources published by NOUS. They're good, but there are a number of solutions out there that can satisfy this requirement.

02:43

This has just met so that you aren't using some random time source that can be entrusted.

02:50

10 5 requirements are used to make sure you put in place controls to protect your audit logs from tampering.

02:57

10 51 is in line with previous requirements.

03:00

If it's not a part of your job function, you should not have access to it.

03:04

10 53 is the best practice. All of your audit logs and need to be shipped from the local systems toe a centralized source.

03:12

This allows you to be able to do some correlation across systems and aid in the ability to detect malicious activity.

03:19

It also adds a layer of protection for your audit locks by separating, separating what's happening on the system from the system itself.

03:25

It should be placed in a location where only a handful of personal have access to them.

03:30

10 54 is the same concept. Just apply to externally facing systems.

03:37

10 55 is that you need to be alerted. If anyone is tampering with log data,

03:40

there shouldn't be any legitimate reasons for audit data to be changed, other than adding more data to it.

03:46

If this is occurring, it should be an immediate cause for alarm.

03:53

Requirement 10 6 is that you need to have in place a process to review logs and security events for all system components to identify anomalies or other suspicious activity.

04:03

So what's the point of collecting all these logs if you aren't going to regularly review them?

04:09

So here's the required for requirement for regularly reviewing your logs.

04:13

The requirement is for daily review

04:15

Right now. The practical way to meet this requirement is with the implementation of a seam type solution,

04:21

something that is able to collect all these logs and generates alerts.

04:26

It is impractical for most environments to try to do this in any way other than with automated tools.

04:32

You can have an environment that generates millions of logs, so it's best to try to automate this work and have someone review the alerts and potential suspicious activity.

04:44

So requirement 10 62 can be a confusing one.

04:47

What are all other system components?

04:50

PC I defines this as systems that are considered in scope

04:56

but which are not critical systems, and neither store process or transmit cardholder data nor provide security service is to the CD.

05:04

Some possible examples could be a stock control or inventory control systems. Maybe some prints servers, assuming there's no printing of cardholder data or certain types of work stations.

05:17

So you have to have a risk management strategy in place that addresses all these types of devices that states How often these logs should be reviewed.

05:28

10 63 is just stating that if you see an alarm or bad behavior that you follow up on it

05:32

and track the incident until its closure or completion.

05:35

If you have a ticketing system in place, it's best to leverage this to provide proof to the auditor of this activity.

05:45

Here's an easy one in concept,

05:46

you have to be able to maintain logs for three months for immediate recall and up to a year for logs that are maintained on backups.

05:55

So this means three months on disks essentially and the other nine months worth could be archived

06:00

if you have enough this space for a year, that's fine, too.

06:05

For service providers, The PC I counsel has implemented additional requirements around security controls

06:12

they explicitly defined which controls need to be notifying.

06:15

But the ambiguous nous of timely leads this up to interpretation.

06:20

Whatever your notification mechanism in timeline, just be able to explain it to your auditor. Why the time you have set is effective for your needs and it shouldn't be an issue for the audit.

06:32

10 81 s stating that service providers just need to be able to respond toe alerts that are generated in tinny.

06:39

This is another control that would benefit from school production.

06:43

Limit what you consider critical controls outside of what is explicitly stated if you can.

06:50

And here's the final requirement of the group

06:54

document document document.

06:56

All of your policies and procedures need to be put in writing and deliver to all those that are impact.

07:02

So in summary, we went over the requirements necessary for logging.

07:06

These logs are integral to your ability to detect, attack

07:11

and track down each of the things that happened during an attack.

07:16

All right, quick quiz

07:18

Audit trails need to be Altera ble by administrators when they're in cohesive.

07:28

This is false.