PCI DSS Part 5.1 - Requirements in Depth

Video Activity

This video is the first of two parts which cover the 12 elements or requirements of the PCI DSS introduced in the earlier videos. Requirements 1-6 are: 1. Firewall and router configuration to protect cardholder data. Separate trusted and untrusted networks. Maintain a security policy for employee-owned devices. 2. Don't use vendor defaults for netw...

Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

1 hour 15 minutes
Video Description

This video is the first of two parts which cover the 12 elements or requirements of the PCI DSS introduced in the earlier videos. Requirements 1-6 are: 1. Firewall and router configuration to protect cardholder data. Separate trusted and untrusted networks. Maintain a security policy for employee-owned devices. 2. Don't use vendor defaults for network equipment configurations. Maintain a secure password policy, create a security baseline for systems prior to connecting to the network, and encrypt all non-console admin access for remote access. 3. Protect cardholder data. Limited storage and retention, don't store entire card number, mask PAN when displayed, and protect keys used for encryption. 4. Protect data in transit. Use strong cryptography and secure transport protocols such as IPSEC and HTTPS. 5. Maintain a vulnerability management program. Use anti-virus software along with a host intrusion detection system and keep them updated! 6. Develop and maintain secure systems and apps. This requires instituting secure coding standards and best practices. Utilize a change control system and consists of a review and approval process. Software is often the weak link in security!

Video Transcription
All right. So what we're going to do now is we're gonna take a little deeper look at each of those 12 requirements. I'm certainly not going to read every one of the elements, but you may want to pause the screen on and really take a look To understand the significance of each one of these requirements. I will also mention to you that not
all are listed in their entirety.
So again, going back to the payment card dot org's site that I had mentioned earlier, you can gain more information. All right, So our first goal here to build and maintain a secure network. Well, the first requirement is that we build and maintain or install and maintain ah, firewall
and router configuration to protect cardholder data.
So what a firewall does its main purpose is to inspect traffic and make decisions to either allow that traffic through work to block the traffic. Another one of the things that we associate with firewalls as a means of separating out trusted networks from untrusted networks.
So what we need to do is we need to make sure that data coming in from untrusted networks
is not allowed in unless there's a specific particular need for that to happen. So the idea of Deny all on a firewall says nothing's allowed through,
and then we can go back individually and say except allow this piece of traffic and this type of traffic on this porter based on this protocol or from this I p address whatever piece of criteria we need. But this denial is fairly common setting on fire walls. We want to keep public access
between the Internet and system components
in the cardholder data environment. We want to provide that isolation, Um, and so even if a user and external user needs access, payment card information will force them to go through a front end interface that limits what they can do and what they can view.
So again, we go back to the idea of separating out, trusted from untrusted.
We're here. It's by using a firewall to do so. The second step, using maybe front in applications or some form of interface, the limit that restriction
personal firewall software being installed on mobile devices or employee owned computers that are allowed to access our network. We're really in a time where many organizations are either considering or implementing what we call B Y o d. Bring your own device.
And we do that to accommodate end users that are more comfortable with one format or another.
But we're also doing is we're opening up ourselves toe having to protect all of these different devices with the different operating systems, the different applications, the different security issues. So what we need to do if there's a system that's not in our physical control at all times,
we need to make sure that we protect that device as much as possible.
Will need security policies in place that dictate what the treatment is of any system that's gonna be allowed on our network. For instance, we might set up network access control
that will only allow access to our network to systems that have current any virus software
or must be up to date systems. You know, that's done through network access. Control is the service, and basically what it does is inspects a system's health before allowing it to join the network, we will have acceptable use policies, will have
computer ownership policies. If you do have a company laptop and take it home, it still belongs to the company will sets the case that needs to be well documented. So still under the goal of having our secure network not using vendor supply defaults. Once again, these defaults are generally set up to be easy to use.
They're not focused on providing security.
So what we have I know one point in time Cisco routers and switches would come with a default password of Cisco. Well, everybody that uses thes devices knows that. And even if you didn't, it's very easy to search for the default settings on the Web.
Often, administrators don't take that extra time to secure their systems. So also along, of course, with default settings, simple settings that are easy to guess, password or, if you're really a secure network password, one
not good choices. So get away from the default settings. And it's not just passwords and user names. Certain operating systems, by default, create shares. Certain operating systems automatically share out the entire C drive
Well, they have restrictions on who can access that, but still anybody that's ever worked with that operating system
nose, so that might be a point of vulnerability. A certain service's air turned on by default that might be vulnerable. Certain service's air turned off by default. So we want to take those default settings and really examine whether or not they meet our organization. Or the best ways to do that is to create a
for our systems and make sure before any system would connect to our company network that the security baseline is installed and applied. So that security baseline is essentially going to be the basic, most minimum security configuration that's allowable every system on my network
and usually have different baselines for different operating systems, or perhaps for different roles within the environment.
But before system comes onto the network, those baseline settings must be applied. Very comparable are very common configurations for baselines. Removing unnecessary service is making sure the systems air patched on dhe. You know any hot fixes, air available,
renaming administrative accounts, disabling guest accounts,
those air. Sure, some of the things that would be part of the baseline configuration.
Now this bottom choice encrypt all non console administrative access Frequently, Um,
we allow network administrators to remotely connected systems or devices, so I might want to reconfigure an access control list on a router that's down in the basement. I'm up on the 12th floor well, traditionally in the past, we might tell that into that. Rather, however,
tell Net is an unsecure utility.
It transmits information and clear text, specifically log in credentials. So instead, we want to use secure protocols or mechanisms like SS H, which is secure. Shell and I don't want this to be overly technical, but ultimately any means of remote access opens us up to vulnerability.
Whether it's wireless connective ity to the network, remote access protocols or mechanisms dial in any of that stuff VPN, that all creates a new vulnerability. So we want to make sure if we are allowing remote access that we do so in a secure man.
Now our next security goal is to protect
the cardholder data.
Well, that makes sense, but exactly how we're gonna do it. And we've already talked about the fact that data can be stored or it can be in transmission, and we have to protect it in both of those states. So when we're talking about storing data, we could also refer to that as data at Rip rest.
We need to make sure that we protect it.
So some of the ways limit storage in retention.
The idea. If you don't need it, don't store it. So, for instance, if I'm a merchant that needs authorization on a credit card number, once I get that authorization, I have no business storing that account number in its entirety. And if I do, that just opens me up to vulnerabilities. Even at
most organizations, even if you do have a required need
for maintaining credit card information or payment card information, often you don't need all the information. That's their, you know, even if you call your payment card provider. When you talk to, for instance, a customer service rep, they may ask you for the last four digits of your card number.
Well, the reason for that is they don't have access to the full account number.
They don't need it, nor should they have it. And if they do have it and stored, they must protect it. So we refer to that as data minimization, Onley store what you need, and if their portions off that sensitive information you can discard, do so
mask the primary account number win displayed, and again you know, I might need your last four digits so I could display those in plain text. But the remaining characters should be masked out when they're typed in. And you know what I'm talking about? They're the *** tricks.
The asterisks that appear when you type in the number. Like with passwords.
I shouldn't be able to view that information.
any keys that air used for encryption? And if you're familiar with cryptography, well, encrypt information based on a specific set of instructions, we refer to those instructions as keys. Well, not only did the keys tell, tell us how to encrypt the information. The keys
generally would tell us, have a decrypt
the information. So anytime keys air being used for the protection of the privacy of information. There's keys need to be protected in stores. Some applications will store those keys in plain text or ah, sometimes users will write down keys in plain text so that they needed again. So we want to make sure that we protect our keys
that as we're doing so, those processes are well documented and that they're consistent.
The other requirement for protecting cardholder data is protect the data in transit.
So once again, this comes back to requiring secure protocols, whether its i p sec or SSL or T l s. We want to make sure that we're not transmitting information and email because e mails not protected by default, that we're not sending
credit card payment card information and taxed or instant messages
these air unsecure technologies. We're not connecting toe websites that don't use https. For instance. We always want to make sure the transmission of this information is protected and encrypted. Now, our next set of goals or our next specific goal actually is to maintain
vulnerability management program.
We have to have an honest assessment. Where are my weaknesses? Because if I don't know what my weaknesses are, I can't close those gaps, and I remain vulnerable. So when we talk about that, any virus, software and programs.
So a lot of the anti virus software today is more than just protection about particular viruses.
Ah, lot of these anti virus programs that you might purchase or you mind install really arm or host based intrusion detection systems. And by that I mean they're not just looking for a specific virus, but they're looking for abnormal activity. They're looking for suspicious behavior,
and that's really where we get the most bang for our buck because there are a lot of types of malicious code
and malicious activity that's far beyond just a virus. So really not just anti virus software, which is the requirement to go that extra step further and get the host intrusion detection systems that are looking for things like applications installed, improper registry access.
You know all of those little elements that are more than just a virus.
it's important we have the software. We have to keep that software up to date.
We have to make sure the software stays running. Some malicious code will go to shut down the anti virus software, so it's very helpful if we have some means of being able to detect. If the software has been turned off.
You know, a lot of times some certain software programs will have a little X down by the system clock. We call that area the system tray,
and that will let me know it's turned off. The other thing that I see if I don't have policies in place preventing this from happening is I'll goto a user's desktop and I'll see there any virus programs turned off. And I'll say, What what's happening here? They'll say, Well, I kept getting these pesky security errors
and I couldn't do what I wanted to do. I couldn't download when I wanted to download, so I just turned the anti virus program off.
That's not helpful. That's not helpful. And it's up to me. Is an end user to know the very negative effects that can have, but also to my network administrators to implement policies that don't allow that to happen? If I am getting disturbed by constant security warnings, there's a very good chance that there are security problems
with my system.
And one of the mottoes that I will always stress is that when you're in doubt, when you're not sure if there's a security related issue or not, when in doubt, check with your security team,
contact your security team, let them know what's going on. Contact the manager.
My motto is, I never want to be a person at the top of the list where bad decision has been made. I would rather my name not be attached to a bad decision.
Yeah, I'm the one who decided to turn off the firewall software or the anti virus program.
No, not me. That's coming off our that decisions being made by someone else. Another requirement in line with maintaining a vulnerability management is I have to start with security in mind. I have to develop and maintain secure applications and secure systems.
Now, really, let's think about that. I want all of you out there
that have ever sat through an introduction to programming class.
Okay, I think a lot of us have, whether it was in high school or college or somewhere along the way, sitting through a programming class and how much of that class was devoted to writing secure code.
And I think I can come up with an answer for you. And that answer is approximately zero.
Programming classes rarely teach writing secure code. They teach how to write functional code, which is not the same thing. So we have to start by training our developers and our programmers to think about security. We as managers have to require security and we have to allow the allow.
The appropriate time in the appropriate resource is
get secure code. So there's plenty of responsibility all the way around. We can't just We can't blame our developers. We haven't trained them. We haven't asked them. We haven't supported them for writing secure code in the past. Bottom line is it doesn't matter where the blame lies in the past. From this step forward, we have to put a focus on security
and really think about it.
We have
all of these mechanisms. We have intrusion detection, intrusion prevention. We have routers with access control list. We have firewalls. We have any virus. Where is this? The weakness lot
that lies in our software. If we would write better software, we would be so much less dependent on our firewalls on our routers, intrusion detection systems. So we want to develop a process that the applications air developed from the beginning, including planning
in accordance with thes best practices within the industry,
change control so very important. And what that means is we have a process in place
that if a changes proposed to our software to our systems that that change doesn't happen on the fly,
that there's a process of submitting the change for review.
The change gets reviewed,
it's either permitted or denied.
Then the changes implemented in the lab environment tested, documented and then pushed out to the production network. We don't ever want to make a change to systems in production, where that that's installing new software, new hardware, upgrading, updating, modifying
without that change being reviewed
and approve. This can lead to system instability. This can lead to compromise. You know, we have to be very rigid about the changes that happen.
Web based applications are frequently vulnerable because anything that we allow access to from the Web, you know, we're taking on this unknown entity. So these have to be well written, and they have to be well protected as well. You know, specific firewalls designed to protect
Web applications themselves
must be present.
Up Next

This series covers the framework governing the self-regulated payment processing industry. Compliance with these standards is critical. Learn the 12 elements of the framework and how they pertain to risk management in relation to cardholder data.

Instructed By