3.9 Requirement 6

00:00

Welcome to the cyber very D mystifying PC idea, says Compliance Course.

00:05

This model will focus on the goals of the PC idea SIS and the requirements associated with them.

00:12

This video introduces you to requirements. Six.

00:15

We will talk about the requirements associated with maintaining secure systems and applications in the CD.

00:23

The learning objective of this video is to discuss some of the ends and outs of each of the mandates associated with maintaining secure systems and applications in the CD.

00:35

A lot of the meat and the goal of maintaining a vulnerability management program comes in Requirement. Six. Developed and maintain secure systems and applications.

00:45

This grouping is all about identifying and prioritizing the vulnerabilities that are associated with your CD

00:52

PC. I also wants to make sure you have in place procedures to securely develop the applications that running your environment

01:00

for software and systems that are being developed by a vendor. You need tohave secure processes for patching newly discovered vulnerabilities and put in place mitigating controls to limit the vulnerabilities potential. To impact the environment

01:14

for software that you develop in house, you have to have proper development lifecycle change control and make sure you address the top vulnerabilities as defined by the open Web application Security Project or a lost.

01:30

So let's start with six that one.

01:33

How are you able to identify the vulnerabilities in your environment and then assigned the more risk rating that reflects the scores that are assigned?

01:42

The easiest way to meet this requirement is to deploy a vulnerability scanner internally.

01:47

As the environment grows, it can quickly become unrealistic to try to manually track all the vulnerabilities for all of the software that is in your environment.

01:56

They're free and open source solutions to meet this objectives if you have a shoestring budget.

02:00

But if you do not want to deploy software to address this requirement, as long as you're able to show an auditor how you're tracking the vulnerabilities and applying your risk rating, it will meet this requirement.

02:15

Once of owner. Once a critical vulnerability is discovered and there is an active exploit, the iterations of that exploit explode. Within days,

02:23

the exploit becomes widely available toe hackers of the active trading or selling an underground markets.

02:29

The most common attacks are not facilitated via the fabled zero day,

02:34

but are more often and not be a vulnerabilities that are fixable that just haven't been

02:38

so. It's important that merchants employ a robust patching infrastructure that not only addresses the operating systems, but also all of the software applications that exist within the CD

02:50

PC. I mandates that critical patches be applied within 30 days of a release.

02:54

For best practice, you should try to do it, eh? You should probably do it faster.

03:00

The auditor will look through your policies and procedures to verify that this is defined and take a sample of systems to see their patch levels.

03:08

The sixth regrouping is focused on the software development life cycle of the merchant.

03:14

If you do not develop any software in house, and these requirements may not apply to you,

03:19

if you do develop in house most of these requirements of best practices anyway and would serve you to reduce the vectors of attack

03:30

well, crime at 63 that one is straightforward.

03:31

All tests and temporary accounts should be removed. Report. Before production use.

03:38

These accounts could be used at the back door or could be discovered by Attackers

03:42

so they should just be removed.

03:46

The 632 requirement is a mandate that code be checked to ensure that there is no insecure code or libraries being used in your application.

03:54

This could be either a mango or automated process, but it has to be done by someone other than the original writer of the code being reviewed.

04:03

Once again, the auditor is going to inspect the documents and interview personnel to evaluate your processes.

04:10

The auditor will also make sure that your code complies with all of the other PC I requirements.

04:15

Listed. Here is a link to the AWAS Code Review Guide to show you some of the components that should be in your code review process.

04:27

The 64 grouping of requirements is all around testing in the change control process.

04:31

A mature organization faction has controls around changes to minimize the potential of disruption due to instability associated with the change or introduction to of a new vulnerability that was not properly vetted.

04:46

Most compliance programs mandate that change control, be a part of your process and procedures,

04:51

and with good reason

04:54

changes could be the difference between previously being in compliance and now being out of compliance

05:00

changes could have a heavy cost. Do defines

05:02

the hood could have a heavy management cost.

05:06

They could change your customers experience for the worst.

05:10

So change control is all about evaluating and addressing all of these concerns as early in the process as possible.

05:18

Requirement 641 states that production should never mix with test environments.

05:24

You need to minimize the access to sensitive data.

05:27

Most developers probably don't need access to PAN data.

05:30

Second is testing could introduce instability to the environment.

05:39

As I mentioned in 641 developers don't need access to production environments.

05:44

If they do,

05:45

then there should be a separation of accounts.

05:47

The data shouldn't use the same account toe access, data and production as they used to do their development. Work

05:57

access should be continuously evaluated for need

06:01

requirement. 643 States that

06:05

you only use test cardholder data for testing.

06:09

Using live data could lead to date a leakage.

06:15

As I mentioned earlier. Requirement 644 mandates All test data and accounts should be scrubbed for being put into production

06:27

before going into change control procedures. Let me first talk about a common question.

06:32

Does every single change in the environment have to go through the change control process.

06:38

The answer's no

06:39

changes that occur regularly and its impact are commonly understood.

06:44

Do not have to go through the full process

06:46

like provisioning a user account

06:48

if you have a full process around that, and it doesn't have to be added to the bureaucracy of change control.

06:55

If you have a load balancer and you need to flip traffic to another server for troubleshooting,

07:00

that doesn't necessarily have to go through the full change control process.

07:04

What you should have is a list of common things that happen in your environment. That exit exempt from going through the change process

07:13

changes should detail what the previous state waas on, what the new state will be After the change has been implemented,

07:20

changes have to be authorized by designated officials.

07:26

Functionality testing is a big one that is commonly missed.

07:30

We're not just talking about the functionality of the application. We're talking about the functionality of the security controls,

07:35

so access controls and put validation. Encryption mechanisms are all among the things that need to be assessed as needed.

07:44

This is as applicable, of course,

07:46

so no need to test controls that are in no way impacted by the change,

07:49

but again, you need to be able to show all facets of the application that are impacted by the change.

07:57

A document. A rollback plan is crucial to your change control program.

08:01

If something goes wrong with the implementation of a change, you need to outline exactly how to roll back the changes in the event that something goes wrong or there's a negative impact.

08:15

Here's another key requirement for a managing her environment. As you operate over time

08:20

as a merchant, you have to be able to keep everything up to date as your CD evolves,

08:26

making sure all significant changes trigger an update to your documentation will facilitate your compliance efforts in the future.

08:37

There isn't a ton to say about the 65 grouping.

08:41

These requirements are all about making sure you have controls in place to protect against the top attack vectors for applications.

08:48

Exploring each of these vulnerabilities and how to protect against them are outside of the scope of this course.

08:54

But I will direct you to a wife's, a wasp site for a cheat sheet

08:58

on what each vulnerability is and how to determine if you are vulnerable.

09:05

Here's a quick look of the 10 vulnerabilities directly listed

09:18

equipment, 66 can be a confusing one.

09:20

This requirement is specifically for public facing applications.

09:24

66 gives you two options to meet it.

09:28

It wants you to either conduct a full security assessment of the application,

09:33

but this is different than a scam.

09:35

They want this vulnerability assessment to be conducted by someone who is independent of the developer of the application.

09:43

It is allowed to be an internal resource, but that resource must operate outside of the group that manages the application.

09:52

If using the internal resource, you must show how they're independent.

09:56

You must also demonstrate that this person is qualified. The conducting assessment

10:01

This person should exist inside of your S, T. L C. And the assessment should be completed before deployment into production.

10:09

The second option is that you have a public big If is that the public facing application should have a Web application, firewall or laugh deployed in front of it.

10:18

This could be implemented in software or hardware running in an appliance or in a typical server.

10:26

It may be a standalone device or integrated into other network components.

10:30

Wafts are designed to inspect the content of the application layer of an I P packet, as well as a content of any other layer that could be used to attack a Web application.

10:43

Some of the features that PC I recommend the WABBIT has is inspect the Web application input and respond by allowing, blocking and or alerting

10:54

preventing data leakage.

10:56

It should enforce both positive and negative security models

11:01

It has to inspect WEB What page content such as hypertext markup language, H demo, dynamic hypertext markup language de HTML and cascading style sheets. CSS

11:15

and the underlying protocols that deliver the content, such as hypertext transfer protocol, A, T, H, T, T P and hypertext transfer protocol over SSL https.

11:28

It needs the inspect Web service messages

11:31

The wife should inspect any protocol proprietary or standardized

11:37

or data constructs proprietary. Your standardized

11:39

that is used to transmit data to or from the Web application when such protocols or data is not otherwise inspected. At another point of the message flow,

11:50

the wife should be able to defend against

11:54

threats to the whap itself

11:56

and it should support SSL and or t l s termination.

12:01

Really, this should just be t l s termination since SSL has been replicated in the PC I mandate

12:11

and the last requirement is that all of the policies and procedures are documented and disseminated.

12:16

Auditors will ask personnel how they're trained and where they can find documentation about the anti virus solutions.

12:24

They should also verify that the procedures are being followed.

12:26

The more documents and artifacts you have,

12:30

the easier it is to prove that as a merchant, you're doing what you're saying. You're doing

12:39

all right. Quick quiz. Oh, sorry. This is a summary.

12:43

We discussed all of the mandates associative the PC I requirement six

12:48

Requirement six is all about making sure you have someone or have secure processes around the development in the management of your environment.

12:58

Okay, sure. False.

13:01

All changes are subject to the change control process.

13:07

Identified. Standard changes that are associated with normal operation do not have to go through the whole process.

13:13

You should have these changes documented with justification for your auditor.

13:20

Custom develop code must be reviewed by the initial developer, the auditor,

13:26

a second qualified developer

13:28

or the CEO.

13:33

I'd go with C on this question because it's the best answer. But technically, the CEO could work, too, if he or she was a qualified developer as well.

13:46

Security assessment of an application is the same as an A S V scan

13:50

can be conducted by the developer

13:52

can be done every five years or must be done by an independent third party.