PCI Requirement 1 Archives

What is PCI Requirement 1.1.5?

It’s not enough that you have a network set up with established policies, procedures, and processes. You also need to ensure that you have someone within your organization that has the formal responsibility of managing the network. PCI Requirement 1.1.5 states that it’s necessary for your organization to have a “description of groups, roles, and responsibilities for management of network components.”

PCI Requirement 1.1.5 ensures that personnel at your organization are aware of who is responsible for managing your assets, and that the person or group who is responsible are aware of their specific responsibilities. If PCI Requirement 1.1.5 is neglected, it could leave your organization’s assets unmanaged and vulnerable.

To prepare for your PCI assessment, the PCI DSS v3.2 says that your organization should verify that the standards in place for firewall and router configurations contain a description of the network manager’s responsibilities. Your organization should also interview the group or individual who is responsible for network management to verify that the roles and responsibilities are assigned as documented.

It could be an individual or a group who is formally assigned the responsibility to manage the network, but whoever manages the network needs to fully understand how to securely manage assets. The network manager needs to have skills from a productivity perspective, but more importantly, from a security perspective. Assessors are looking for someone who has the necessary skills to manage the network securely.

It’s not enough that to have a network set up. We have established policies, we have procedures – it’s really not enough that we do that. You have to ensure that you have someone within your organization that has the overall responsibility of managing the network. The management of this network could be assigned to an individual, it could be assigned to a group, but somebody has to formally be assigned this role. The assignment of this role needs to be to somebody who truly understands how to manage these assets not just from a productivity perspective, but also from a security perspective, understanding that we have these assets in the environment that needs to be managed securely.

Often, organizations don’t quite understand that managing your assets from a productivity perspective isn’t always necessarily the same type of skills that are required for managing the asset from a security perspective. So, when you’re defining who’s specifically responsible for managing the security of these assets, understand that from an assessment perspective, assessors needs to see that the network manager has the necessary skill set to manage these things securely.

What is PCI Requirement 1.1.4?

PCI DSS Requirement 1.1.4 requires “a firewall at each internet connection and between any demilitarized zone (DMZ) and the internal network zone.” PCI DSS v3.2, the current version of the standard, says that the purpose behind PCI Requirement 1.1.4 is, “Using a firewall on every internet connection coming in to (and out of) the network, and between any DMZ and the internal network, allows the organizations to monitor and control access and minimize the chances of a malicious individual obtaining access to the internal network via an unprotected connection.”

Your organization needs to establish a DMZ for your inbound internet access, including a supporting web server, email services, or FTP. A DMZ is a physical or logical subnetwork containing an organization’s external facing services to untrusted networks, such as the internet. It adds an additional layer of security to your internal network by acting as a buffer between your internal corporate network and untrusted networks. By segmenting this untrusted network from your corporate environment, you are minimizing the threat of unauthorized access to your internal network.

We have to establish a DMZ, a demilitarized zone, for your inbound internet access. If you have inbound internet access – supporting a web server, supporting email services, supporting FTP – we want to make sure that those particular assets do not reside within the corporate aspect of your environment. We want to establish a small area that allow for those assets to sit in that have more open ports and a little less security than your entire corporate environment.

What we look for as an assessor is that you have a firewall that exists between your internet connection and the DMZ. And then, between your corporate network or area where you’re trying to secure your data/CDE, we look to see that there’s another firewall there. This doesn’t necessarily have to be 2 physical assets. It could be the same asset, as long as you’re routing traffic into an area of the network that is then managed, secured, and controlled. As the traffic flows in from the internet, we want to terminate it into the DMZ, we want to inspect it for authorize services, protocols, and ports before that traffic is then allowed into your network.

This exclusive video series, PCI Demystified, was developed to assist your organization in understanding what the Payment Card Industry Data Security Standard (PCI DSS) is, who it applies to, what the specific requirements are, and what your organizations needs to do to become compliant. In this episode, Jeff Wilder walks us through PCI Requirement 1.

The Payment Card Industry Data Security Standard (PCI DSS) was jointly developed by the payment card brands to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. Its purpose is to ensure that all of that data that lives within the Cardholder Data Environment (CDE) is protected and secured from theft or unauthorized use. If you are a merchant, service provider, or sub-service provider who stores, processes, or transmits cardholder data, you are subject to comply with the PCI DSS. The current version, PCI DSS 3.2, has approximately 394 controls, 6 control objectives, and 12 major subject areas. The 12 requirements are:

Install and maintain a firewall configuration to protect cardholder data
Do not use vendor-supplied passwords and other security parameters
Protect stored cardholder data
Encrypt transmission of cardholder data across open, public networks
Protect all systems against malware and regularly update anti-virus software or programs
Develop and maintain secure systems and applications
Restrict access to cardholder data by business need-to-know
Identify and authenticate access to system components
Restrict physical access to cardholder data
Track and monitor all access to network resources and cardholder data
Regularly test security systems and processes
Maintain a policy that address information security for all personnel

PCI DSS Requirement 1

The PCI DSS Requirement 1, which states, “Install and maintain a firewall configuration to protect cardholder data.” PCI Requirement 1 addresses building and maintaining a secure network. This requirement requires your organization to maintain the authorized inbound and outbound traffic of your environment. Requirement 1 also focuses on managing the changes that happen in your environment and maintaining the documentation and program. It’s also about maintaining strict rules about what traffic is allowed in and out of that environment. It’s also about establishing a DMZ and limiting the traffic only to that which is necessary. We will explain the main topics of Requirement 1, like firewalls, network traffic, controls, documentation, and so much more.

Introduction to Requirement 1

So PCI DSS Requirement 1 is about maintaining a secure network. It’s about maintaining the authorized inbound and outbound traffic in and out of your environment. It’s about managing the changes that happen in that environment, maintaining the documentation, and maintaining the program. It’s also about maintaining strict rules about what traffic is allowed in and out of that environment. Lastly, it’s about establishing a DMZ and limiting the traffic only to that which is necessary

We find that most organizations struggle with the documentation aspect of a PCI assessment. Established best practice states, “If it’s not written down, it’s not happening.” Organizations need documented policies, procedures, and standards to control risks to business assets, but to also have a common understanding and language to create consistency among the culture of your organization. Small organizations often question why they need to document how their organization runs, especially if there are only a few people in the company. We think that’s the perfect example of why your organization, no matter the size, needs documentation; what if something happens? Who would know how to securely operate your organization? You need to have the proper policies, procedures, and standards in place to ensure the ongoing continuity and security of your organization.

In order to create and document proper polices, procedures, and standards, you need to understand the differences between them. A policy is an executive level document that defines that something must be done. For example, a policy outlines what employees must do or not do, directions, limits, principles, and guides for decision making – Policies are the law at your organization. A procedure is the counterpart to a policy; a policy defines that something must be done, but a procedure defines how you do it. A policy defines a rule, and the procedure says “This is who is expected to do it, and this is how they are expected to do it.” Standards are the tools, means, and methods that you will use to meet policy requirements.

Creating procedures is where most organizations tend to struggle. A procedure should provide very clear, step-by-step instructions on how something must be done or is to be done. Procedures are instructions on how to run your business. Your organization needs to have this documentation in place to define how to complete tasks securely to ensure the ongoing operation and security of your organization.

Policies, procedures, and standards should be written at a level so that someone with knowledge of the topic could read the policy or procedure and be able to carry out the task that is detailed.

If you need help documenting your policies and procedures or want to learn more about how to write them, contact KirkpatrickPrice or check out our Style Guide to Creating Good Policies and our Style Guide to Writing Good Procedures.

Policies, Procedures, and Standards

Now, I’d like to talk about policies, procedures, and standards. We find, here at KirkpatrickPrice, that a lot of organizations really struggle with the documentation aspect of an assessment. So, we’re going to spend a little bit of time now talking about the difference between policies, procedures, and standards.

At the top of this pyramid, if you would, is a policy. A policy is an executive-level document that defines that something must be done. This is something that’s an edict, that’s a directive by your executive-level management that says “Thou shalt do these things.” The next step down is our standards. What are the tools, means, and methods that you’re going to be using in order to meet these policy requirements? Lastly as part of this, we have procedures. This is where most organizations tend to fail. Having a set of standard policies and procedures is often required. Where a policy defines that something must be done and a standard will define the tools, means, and methods for how we’re going to do it, a procedure defines how we’re going to do these things. A procedure should be very clear in providing step-by-step instructions on how something must be done or how something is to be done. For example, if somebody should go on vacation for a couple of weeks, we would expect them to hand off the policy, procedure, or standards documentation and someone else to be able to carry on that activity securely. These are the instructions on how to run your business.

If you’re a small organization, 2 or 3 people, we often hear the argument, “I’m the only one that does this, so why do I need to document what I do?” Well, I think that’s the perfect example as to why you need to document. What if you’re not around anymore? We need to make sure that we have the processes in place that define how to perform a task securely to ensure the ongoing continuity and security of your organization.

Please review your documentation, please review your audit standards and understand that each of these particular controls often needed and they’re distinctive in nature. As an organization, you can have one monolithic policy set; one policy that has all of the necessary statements. You can have one set of procedures that cover everything in your environment. You can have one document for each; we really don’t care. What we do care about is when a requirement says to demonstrate that you have a policy, we look for the policy. Where there’s a procedure required, we actively look for the step-by-step procedures.

Policies, procedures, and standards should be written at a level that you can hire somebody or give these documents to somebody with knowledge of the specific topic, and that individual could be able to carry that task on. We don’t expect you to be able to educate someone or take them from the ground level to expert level; someone who has knowledge of the topic should be able to read the policy or procedure and perform the task that’s detailed.

Properly scoping your environment is the most important initial step of becoming PCI compliant. The scope of the Cardholder Data Environment (CDE) determines the extent to which all PCI DSS controls must be in place. If an asset is in scope, all controls will apply. If an asset is not in scope, then there’s no concern to PCI. Errors in scoping can lead to serious consequences, so it’s important to define an accurate scope before beginning your PCI DSS audit. No matter what kind of data you’re protecting – ePHI, cardholder data, financial information – you need to understand where your assets reside and what controls are protecting them. If you don’t know where your data is, how do you plan to protect it?

So, how does your organization determine if an asset is in scope? Any people, process, or technology that stores, processes, or transmits cardholder data, is considered to be within your CDE and in scope for your PCI DSS audit. The rules defined by the PCI Security Standards Council also state that:

If your organization has any devices that provide security/authentication services, such as a firewall, router, or patching server, then those devices are considered in the CDE and part of your scope.
If your organization has an asset that has connectivity into the CDE, that asset is in scope.
If there are any routing rules that allow traffic into your CDE, that traffic brings those assets into scope.
If your organization has an asset that is deemed to have impact over the security of the CDE in any way, it’s also considered in scope.

There will be some gray areas and areas where your organization may struggle to determine whether a particular asset is in or outside of the scope of your PCI audit. But, there are typically 6 questions you can ask to determine whether something is in-scope. If the answer to any of these questions is yes, then that asset is in scope:

Does the asset store cardholder data?
Does the asset process cardholder data?
Does the asset transmit cardholder data?
Does the asset provide security services within the CDE?
Is the asset connected to the CDE?
Could the asset impact the security of the CDE?

Establishing Scope of Your Environment

One of the most important things your organization will do during your assessment process is to try to understand what’s in-scope. Whether it be HIPAA data, PCI data, any type of data, or financial information, you need to understand where your assets reside and what the controls are that you have in place to protect them.

As an assessor, part of the process is spending time with your organization and working with you to understand the scope of your environment. If your systems, your processes, or your people somehow have the ability to negatively impact the security aspect of this data we’re trying to protect, we look to make sure that you have appropriate controls in place. We try to, if you would, draw a circle around the assets that are in question and apply those controls to that. When we look at it from a security perspective, you must understand that if you don’t know where your data is at, how do you expect to protect it?

So, establishing the scope of your environment is one of going to be one of the most important things that you do in maintaining security. You need to ensure that you have the appropriate controls applied in the appropriate places.