The Payment Card Industry Data Security Standard (PCI DSS) is the security standard for protecting payment card data. Navigating the requirements of the PCI DSS and implementing the technical security controls can be quite complicated.

If your systems touch credit card data in any way, your bank and the major card brands require you to be PCI compliant. Hardened systems managed by experienced security professionals who know how to implement the PCI DSS are the key to avoiding audit failures or, worse, breaches and expensive fines and reputational damage.

Your specific PCI compliance needs depend on exactly what you do with the card data (is card data stored or does it only pass through on the way to a payment gateway, etc.), as well as how many card transactions your company processes. This determines your verification requirements (whether you can self-assess or whether a third party auditor must attest to your compliance) and exactly what you must do to become compliant (which Self-Assessment Questionnaire) must be completed. It could be as simple as satisfying a dozen requirements or as complicated as several hundred.

Compliance vs. Security

All companies with a compliance obligation must remember that the point of compliance is to impose a certain level of security. Security is the ultimate goal, not necessarily compliance. Remember that the PCI DSS is the minimum acceptable practice for protecting payment card data.

Being compliant does not mean you are secure; it merely means you have “checked the boxes.” There are many things which could still result in a compromise such as an employee accidentally leaking his passphrase by getting his computer infected with malware, a bug in a web application exposed directly to the Internet, etc. Occasionally it becomes necessary to go beyond the security requirements spelled out in the “letter of the law.” Compliance requirements should be considered “minimal acceptable practice” and not strictly “best practice.”

What’s more, both compliance and security are ongoing efforts; the work is never-ending. There are always new vulnerabilities discovered, new versions of software coming out, and advances in the state of the art in terms of attacking and defending.

Prevention, Detection, Response

A solid PCI security program has three main components: prevention, detection, and response. Each of the security controls described herein can generally be classified as one of these. Using secure passwords (Requirement 8.2.3), keeping systems patched up (Requirement 6.2), and even employee background checks (Requirement 12.7) are considered prevention. These seek to avoid trouble in the first place.

But despite best efforts, there is no such thing as 100% security: prevention cannot always be successful. We must also plan to detect problems or situations which could lead to intrusion and limit damage. In addition, a plan must be in place to respond to an intrusion to prevent the situation from getting worse and to ultimately resolve the issue.

Risk Mitigation Is the Name of the Game

There is no such thing as perfect or complete security. Each security control implemented is designed to reduce the probability of having an incident in some way. Sometimes it may seem that any one particular security control may not be terribly critical but remember that probabilities add up and anything that can be done to reduce the probably by even 1% can be worth it. To be able to mitigate risk, an assessment must be done to identify the risk.

PCI DSS Scoping

The “scope” of a PCI Card Data Environment (CDE) environment is any system which contains payment card data and any system which touches or is directly accessible by a system which contains payment card data. There are some additional rules also but this covers the general idea. The PCI DSS is applicable to any systems which are “in scope,” and all such systems must be secured per the PCI DSS. A good secure server hosting company can help you analyze your systems, determine the scope, and most importantly minimize the scope. To minimize the scope of the CDE is to reduce risk, reduce expense, and reduce the burden of maintaining a compliant environment.

Security Controls

A security control is anything which reduces risk. Your host company should conduct a risk assessment of your environment and identify the risks. Each risk identified in the risk assessment must be addressed by a security control which is intended to reduce or mitigate that risk. In addition to the PCI DSS, publications such as NIST SP-800-53 can be used for additional guidance in implementing security controls.

The Requirements of the PCI DSS

The PCI DSS is a list of tasks you are required to complete in order to secure your Card Data Environment (CDE). While the PCI DSS has only 12 major requirements, each one can have a dozen or more sub-requirements. Exactly which of these requirements your company must meet depends on what you do with the card data. Ultimately, it is based on risk: If you store card data you will have to meet every one of the requirements. If you don’t actually store the data and only have it momentarily as it passes through your systems on the way to the payment gateway, you must only comply with a subset of the requirements.

Below, we take a quick look at the 12 major requirements and a few of the sub-requirements.

#1: Install and maintain a firewall configuration

In order to protect cardholder data, firewalls must be configured with both ingress and egress filtering. Most people are familiar with the idea of firewalls blocking inbound connections but blocking unusual outbound connections is also necessary to prevent many kinds of attacks from working as well as exfiltration of data. Firewalls logging blocked outbound connections is an excellent source of information about unusual things happening within the network.

Network segmentation is key in reducing the PCI scope of the CDE. The client’s environment will be maintained on its own private network separated from non-client systems via firewalls using VLANs. Web application servers, database servers, and development servers will all reside in their own separate VLANs and be protected from each other to the greatest extent practical. The CDE will reside in its own isolated subnet or subnets separate from other systems which are not involved in the processing of payment card data.

#2: Do not use vendor-supplied defaults for system passwords and other security parameters

This requirement covers not only using default passwords (which attackers frequently use to attempt access) but also ensuring that each system performs one task, disabling unused services, etc.
#3: Protect stored cardholder data

Your host server vendor and help to analyze the need to store cardholder data, what forms of data are permissible to store and what are not, and implement strong encryption or other security controls as required to meet Requirement 3. Proper key management is a big part of keeping encrypted data secure, and Requirement 3 has a number of sub-requirements in this regard.

#4: Encrypt transmission of cardholder data across open, public networks

When payment card data flows over open networks, encryption must be utilized: your vendor should use SSH for administrative functions, GPG for email, and SSL for webserving of such information. Standard Linux whole disk encryption is also available although generally only recommended for mobile devices such as laptops.

#5: Protect all systems against malware and regularly update anti-virus software or programs

Automation should ensure that anti-virus is installed on all systems, is up to date, and is configured to scan properly, generate audit logs, etc. Furthermore, systems are in place to provide monitoring and alerting to the discovery of viruses or malware on servers via a centralized log collection system.

#6: Develop and maintain secure systems and applications

Your vendor should go to great lengths to harden their systems to ensure they are as secure as possible. A solid Linux host hardening program is based on the NSA Linux Hardening Guide also known as the NSA Systems Network Attack Center (SNAC) hardening guide.

While not required by PCI, one of the best hardening measures is the use of an automated management system known as Puppet. This system automatically applies many configuration changes to a stock Linux server. It currently consists of over 3000 lines of code and covers automatic configuration and maintenance of a multitude of security controls. Implementing SELinux on all security hardened servers is also a good idea. This is a system of mandatory access controls (MACs) developed by the NSA.

Reviewing a number of sources of security information on a daily basis (Requirement 6.1); applying security patches within 30 days (Requirement 6.2); and the development of secure web applications (Requirement 6.3) are also critical.

#7: Restrict access to cardholder data by business need to know

This involves using standard access control methods provided by the operating system such as users, groups, etc. The systems will be configured to allow access only to those who have a business justification. Two-factor authentication, public key authentication, etc., should be used as appropriate.

#8: Identify and authenticate access to system components

This requirement says each individual user must have a unique user ID (no shared IDs) to ensure personal individual accountability (Requirement 8.1.1). It also calls for sound account management practices, strong passwords, and lockout after a particular number of failed authentication attempts.

#9: Restrict physical access to cardholder data

Data center facilities should be audited annually to SSAE 16 Type II and have a 24/7 manned physical presence. The data center should extensive video camera coverage (Requirement 9.1.1), and visitors should be logged by required sign-in (9.4.4) etc. All equipment should also be logged as it physically enters and leaves the datacenter. When equipment is retired it is disposed of properly to ensure that card data is not compromised including the secure wiping or physical destruction of media (Requirement 9.8).

#10: Track and monitor all access to network resources and cardholder data

Regular analysis of system log files is critical for detecting intrusions, intrusion attempts, and software misconfigurations. It is important to get the system log files off the server on which they are generated and onto a separate secured system to prohibit tampering. System log files will be sent in real-time to a central log server where they can undergo weekly audit log reviews per requirement 10.6. Other regularly scheduled audits will be conducted on a daily, weekly or quarterly basis.

#11: Regularly test security systems and processes

Requirement 11.4 calls for intrusion detection systems for information system monitoring, near real-time alerting of issues, etc. One of the best ways to monitor network activity and detect network attacks is to use a Network Intrusion Detection System (NIDS). Such a system inspects all traffic going into and out of the network and applies rules and heuristics to network traffic to attempt to detect attacks and alert security personnel of potential issues. Data coming from the NIDS must be reviewed regularly and in a timely manner to ensure early detection of issues.

#12: Maintain a policy that addresses information security for all personnel

The security policy is a required document which ensures that all personnel with access to the card data environment know their responsibilities with respect to security. It lays out the policies and procedures that personnel are expected to follow. A copy signed by each individual with such access must be kept on file. There are many risks for which there is no technical solution as the risk is due to individual behavior and actions.

Conclusion

The major points of PCI compliance have now been covered and we hope you have a better understanding of exactly what a PCI compliant hosting solution looks like. PCI compliance is a team effort, and the secure hosting company you choose should help your company move towards obtaining and maintaining PCI compliance — not just as a one-time task but as an ongoing campaign.

Additional Resources: For additional information please visit the PCI Compliance Website.

via:  enterprise-security-today