What is PCI 3.0 and How Does It Differ from PCI 2.0?

The Payment Card Industry Data Security Standard (PCI DSS) applies to companies of any size that accept credit card payments. The effective date of version 3.0 of the standard was January 1, 2014, but existing PCI DSS 2.0 compliant vendors had until January 1, 2015 to move to the new standard. Some of the changes are not required to be in place until June 1, 2015. This blog post from Kivu will explain what the new standards are and review some of the most critical issues involved with compliance.

PCI 3.0 is not a wholesale revision of PCI 2.0. The 12 core principals of PCI compliance remain intact. PCI 3.0 is the clarification and revision of all 12 principals and is roughly 25% bigger than PCI 2.0, including 98 upgrades. Some of the upgrades are small but others are significant. PCI 3.0 will be harder and more expensive to implement than PCI 2.0. Organizations should expect that the PCI 3.0 assessment will be similar to PCI 2.0 but more transparent and consistent.

A major concern for merchants implementing PCI 3.0 is how they will be able to afford the increased cost of compliance. PCI 3.0 requires additional processes and procedures that many organizations might not be prepared to implement.

New Key Areas for PCI 3.0

Segmentation of Card Data Environment (CDE) – Penetration Testing

PCI 3.0 is a great improvement over PCI 2.0 because it segments the Card Data Environment (CDE) from other networks. During the breach at Target, contractors had access to the client network, putting the whole CDE environment at risk.

The cost of segmenting the CDE environment will be a burden on the merchant, but it is a significant step towards reducing risk and exposure. Penetration Testing (testing a computer system, network or web application to find vulnerabilities that an attacker could exploit) will be critical. Qualified Security Assessors (QSAs) will have a tough job auditing the new guidelines and results.

Key Takeaways

  • PCI 3.0 has to be implemented by June 2015.
  • PCI 3.0 requires that all merchants be PCI compliant to undergo a Penetration Test.
  • Merchants need to ensure that correct methods are used to segment the CDE environment from the client network.
  • The contractor network must be segmented from the client network.
  • The Best Practice Framework will be based around NIST SP800-115.
  • Merchants must be diligent in their selection of penetration testing services.

System Inventories

Maintaining system inventories is not an easy task, and accurate system inventories have been difficult to accomplish under PCI 2.0 What is different with PCI 3.0?

The inventory list under PCI 3.0 just grew bigger. Now, maintaining an inventory of hardware, software, rules and logs will be an even more difficult task in order to remain in compliance. Documenting components and inventory is time consuming, and inventory changes frequently. Who will be in charge of accomplishing this within an organization, and how reliable will the inventory list be? What happens when virtualization/cloud is thrown into the inventory mix? What about geographic locations?

We at Kivu see maintaining a system inventory as an evolving cycle with constant issues.

Key Takeaways

  • Maintaining a reliable, timely inventory will be somewhat impossible.
  • The merchant’s IT & compliance teams will have to spend more time creating inventories.
  • Merchants need to know who will be responsible for maintaining system component inventories that are in scope for PCI DSS (Hardware & Software).
  • Merchants must maintain an inventory of authorized wireless access points, including their business justification.
  • Documenting components and functions will be a continuous cycle.

Vendor Relationships

Explicit documentation of who manages each aspect of PCI DSS compliance is a critical improvement of PCI 3.0 over PCI 2.0. Who owns what, the service provider or the organization? Management of each aspect of PCI DSS compliance should be well documented in every vendor contract agreement.

Kivu recommends a written agreement with service providers verifying that the provider maintains all applicable PCI-DSS requirements. Getting service providers to agree will be a daunting task. Will vendors want to take this responsibility? In refuting PCI reports, identifying who is at fault is a common problem. If there is a breach, who is liable?

Key Takeaways

  • In PCI 3.0, detailed contractual language and service provider roles and responsibilities are much more of a focus.
  • Merchants should decide who owns each aspect of PCI compliance.
  • PCI compliance has to be written into the vendor contract agreement, with specific language on who owns what.
  • Outline where responsibility lies for control over compliance.
  • Providers must give their customers written documentation stating that they are responsible for the cardholder data in their possession.

Anti-Malware Systems

PCI 3.0 places a new emphasis on identifying and evaluating evolving malware threats targeted at systems NOT commonly considered to be affected by malicious software. Advanced research capabilities or Intel on malware threats is seen as a proactive measure, but who will provide these proactive services to merchants? How can this be enforced?

Who will be responsible for keeping abreast of threats and making sure anti-malware systems are patched and configured correctly? It is critical for the PCI Standards Council to release a recommended list of anti-malware vendors and provide guidelines for merchants.

Key Takeaways

  • PCI 2.0 only states that antivirus software should be in place. PCI 3.0 takes it to another level.
  • PCI 3.0 states that if malware emerges for PCI systems, the merchant should know about it. There needs to be a process that makes sure this happens.
  • PCI QSAs will need to scrutinize anti-malware controls on all platforms.
  • Technical planning and strategy will involve more paperwork for merchants.
  • Specific authorization from management to disable or alter operations of all antivirus mechanisms should be a policy.
  • An anti-malware system should automatically lock out the user for trying to disable it.
  • Merchants will need to justify why they don’t have anti-malware software running on non-windows platforms. This is critical because it causes organizations to think carefully about evolving non-windows threats.

Physical Access and POS System Inventories

PCI 3.0 states that physical access to a merchant’s server room should be restricted, whether the room is in a closet in the back of the store or in a high-end data center. Physical access should be limited to certain personnel, and all others should be escorted and signed in and out of the room. Restricting admission limits the risk of unauthorized access to POS devices and back end systems that could potentially be swapped out by unauthorized individuals.

Maintaining an inventory of POS hardware and conducting frequent spot checks to ensure serial numbers match will be critical to staying compliant under PCI 3.0. POS device inspections should be a best practice, but how many merchants even have a list of their POS devices?

Key Takeaways

  • Control physical access to the server room for all on-site personnel based on individual job function. Access should be revoked upon termination.
  • Maintain an inventory of all POS devices and implement controls to protect these devices.
  • POS device inspections should be a best practice. Periodically inspect POS devices and check serial numbers to ensure devices have not been swapped out.
  • Procedures for frequently testing POS devices should be implemented.
  • Provide security awareness training to employees that use POS systems to identify suspicious behavior.
  • PCI 3.0 mandates that service providers with remote access to the CDE must use a unique authentication credential for each customer environment.
  • Access needs and privileges for all job functions allowed access to the CDE must be formally defined and documented in advance.

What Other Changes Should We Expect with PCI 3.0?

Following are some moderate changes worth highlighting:

  • Risk assessments are now to be performed annually, as well as whenever significant changes are made to the Card Data Environment. What constitutes a significant change to the environment? There are no guidelines that specifically address this.
  • New password management processes/controls are being enforced and met.
  • The CDE must be formally defined, with an up-to-date diagram that shows payment flow across systems.
  • Merchants need to implement file change detection systems and then investigate and respond to all alerts generated by this system. This type of system can generate many alerts every day. Kivu recommends that merchants understand who will monitor these alerts and review and document responses.
  • Daily review of logs is required. Again, who will do this?
  • QSAs will have more responsibility to enforce the new guidelines.
  • PCI 3.0 will increase compliance costs, and those who complain may not fully understand the reasons for the process mandate.
  • There is a recommendation to avoid service providers that are non-compliant.
  • Memory scraping became a best practice for PCI 3.0.

Has the Value of PCI Standards Declined?

It is tough to argue against good security and retailers accepting more responsibility for it. The buck has been passed to the retailer, although banks should take more responsibility to provide more security as well through chip technology or point-to-point encryption. Some retailers are moving ahead with tokenization and point-to-point encryption because they believe that PCI 3.0 compliance is not enough.

What Failures Do We See in PCI 3.0?

The PCI Security Standards Council has missed some key opportunities to clarify the standard and to address compliance as it relates to emerging technologies.

  • One significant issue is the failure of PCI 3.0 to address virtualization, cloud and mobile payment providers. Merchants are frequently using these 3 areas, but PCI 3.0 does not address them in detail nor provide merchants with guidelines.
  • PCI 3.0 continues to ignore mobile payment processing and mobile device security, leaving merchants who support mobile payment technology on their own to determine how to be compliant. Card brands are reluctant to put security constraints on mobile technology through fear of stifling the growing revenue expected from mobile payments.
  • Some merchants remain non-compliant with PCI 2.0, yet they are expected to be compliant with PCI 3.0 by June. How will they be able to make all of the changes necessary? Will some merchants be allowed to become PCI 2.0 compliant at first and given additional time by the PCI Security Standards Council to comply with PCI 3.0?

Is PCI 3.0 Worth It?

PCI 3.0 is bigger, therefore harder and more expensive to implement than PCI 2.0, but it offers additional, critical security benefits. It will take more time and resources from merchants to stay in compliance with PCI 3.0. We at Kivu believe that going forward, it would be best to integrate PCI compliance activities into an organization’s year round IT Security Management process.

Most computer compromises aren’t discovered until after an attack—sometimes days or weeks later. Shutting down a computer may halt malware activity, but it could have negative and unforeseen consequences. For example, it could become difficult to retrace information infiltrated by a hacker or botnet. This is particularly important if significant time has transpired between an attack and discovery of malware.

During a forensic investigation, there should be a balance between rushing to remove malware and understanding the scope of the malware infestation in order to find a solution that deters future attacks.

What is Malware?

Malware is software that is designed for illicit and potentially illegal purposes. Malware may be a single software program or a collection of programs used to accomplish tasks such as:

  • Obtaining system control—for command and control of a computer
  • Acquiring unauthorized access to system resources—network intrusion
  • Interrupting business operation
  • Gathering information—reconnaissance
  • Holding digital assets hostage—ransomware

How Does Malware Infection Occur?

The Internet has opened the door to broad distribution of malware. It is possible for malware to originate from sources such as email, instant messaging, or infected file downloads. Malware can also spread through USB devices or connectivity to public WiFi hotspots.

The most complex malware tools may use a combination of distribution methods to infiltrate an organization. For example, an email may contain a hyperlink to a website that causes “dropper” software to download. The dropper software performs reconnaissance of its host computer and transmits results out to another computer on the Internet. The second computer analyzes the reconnaissance results and sends back malware that is customized to the host computer.

What are Common Types of Malware?

Virus. Virus software refers to software that inserts malicious code into a computer and has the capability of spreading to other computers. The ability to propagate is a requirement for malware to be classified as a virus or worm.

Worm. Worms are a type of malware that propagate across networks. A worm finds its way by reading network addresses or email contact lists and then copying itself to identified addresses. Worms may have specific capabilities, such as file encryption or installation of certain software, including remote access software.

Trojan Horse. This type of malware enables unauthorized access to a victim computer. Unauthorized access could result in theft of data or a computer that becomes part of a denial-of-service (DDoS) attack. Unlike viruses or worms, Trojan horse software does not spread to other computers.

Rootkits. Rootkits refers to malware that takes control of a host computer and is designed to evade detection. Rootkits accomplish evasion through tactics, such as hiding in protected directories or running hidden process names on DLL’s (Dynamic Link Libraries) as legitimate files, without the computer or user noticing an abnormality. Rootkits may defend themselves from deletion and may have the ability to re-spawn after deletion. Most notably, rootkits have the potential to operate in stealth mode for extensive periods of time and to communicate to external computers, often transmitting collected data from a victim computer.

Spyware. The purpose of spyware is to collect data from a victim computer. Spyware may exist as malware that is installed on a host computer or embedded within a browser. Spyware may collect data over an extensive time period without the victim ever knowing the extent of the spying activity. Spyware may collect keyboard strokes, take screenshots of user activity, or utilize built-in cameras to record video.

Browser Hijacker. This malware takes control of a user’s browser settings and changes the default home page and search engine. Browser hijacking software may disable search engine removal features and have the ability to re-generate after deletion. There may also be persistent, unwanted toolbars that attach to a browser.

Adware. Adware refers to software that has integrated advertising, particularly freeware software. Adware displays advertisements within the freeware product and transmits collected data back to a controlling party (e.g., an advertising distributor). A software creator may utilize advertisements to earn advertising revenue.

Ransomware. Ransomware is malware that encrypts part or all of a host computer. Encryption locks a victim out of important files or a computer until a ransom demand is paid, possibly in the form of bitcoins. If the ransom is paid, the victim has no guarantee that the ransomware will de-crypt the computer.

Investigating Malware

When a malware infection is suspected, care should be taken to investigate and collect evidence where possible while performing radiation to remove the malware infection. The following guidelines should be considered when malware is suspected. If a forensics team is involved with the investigation, the following points will be addressed by forensics examiners.

  1. Assess the implication of powering down the potentially infected computer. Powering down a computer may stop malware in its tracks and result in the loss of potential evidence. In the case of ransomware, a shutdown could results in permanently unrecoverable data. The first response to possible malware infestation should be an evaluation of the victim computer and gathering of key evidence. If the malware is associated with network intrusion or other nefarious activity, evidence gathering may extend across multiple computers and the respective network that hosts the victim computer.
  2. Collect a sample of Random Access Memory (RAM). RAM is temporary memory that exists while a computing device is powered on. RAM is particularly important since malware has the ability to operate (and hide) in RAM. Capturing an image of the infected computer’s RAM, prior to shut down, enables a forensic examiner to assess the potential activity and functionality of the malware. Artifacts that may reside in RAM include:
    • Network artifacts, such as connections, ARP tables, and open interfaces
    • Processes and programs
    • Encryption keys
    • Evidence of code injections
    • Root kit artifacts
    • DLL and driver information
    • Stored passwords for exfiltration containers
    • Typed commands in the DOS prompt
  3. Identify and preserve log files. Log files record a variety of information about system and application usage, user login events, unusual activity such as a software crash, virus activity, network traffic, etc. In the event of a potential malware infection or network intrusion event, log files should be collected and preserved for further analysis. If logging activity is turned off or log files are set for overwriting, they may be limited in value for an investigation.
  4. Interview users who may have received suspicious emails or observed unusual computer activity. Computer users and IT staff may have important information regarding the origin, timeline and possible activity of the malware. Early in an investigation, interviews should be conducted to assess the potential scope and breadth of an incident. If malware was introduced through user activity, such as a phishing email, the suspect email may still reside in a user’s email. In the case of malware that entered a computer through a software vulnerability (e.g., code injection through an unsecured website), IT staff may have information about unusual events in system logs or data leaving through a firewall at unusual times (e.g., after business hours).
  5. Determine whether to investigate other computers. Malware may spread through computers within the same network segment or a shared file server. Investigation of malware should include scans of potentially connected computers to assess the possibility of further malware infestation. Additionally, if external connections such as Remote Desktop or GoToMyPC exist and are active, then a determination should be made to analyze externally connected computers.

For more information about malware infection and forensic investigation, please contact Kivu.