Welcome!

@CloudExpo Authors: Yeshim Deniz, Elizabeth White, Liz McMillan, Zakia Bouachraoui, Pat Romanski

Related Topics: @CloudExpo, Mobile IoT, Cloud Security

@CloudExpo: Blog Feed Post

PCI DSS: What You Need to Know By @GiladPN | @CloudExpo

Lack of education and awareness around payment security

By Lohit Mehta

Every organization should follow a proactive rather than a reactive approach to protect against threats, risks, and vulnerabilities to which if their IT infrastructure is exposed can lead to data loss, regulatory penalties, lawsuits, and damaged reputation. Moving on the same lines, to reduce credit card fraud via its exposure, a standard known as Payment Card Industry Data Security Standard (PCI DSS) was formed.

History

Payment Card Industry Security Standards Council (PCI SSC) had developed a standard known as PCI Data Security Standard (PCI DSS), which comprises 12 core security areas to protect credit card holder data from theft, misuse, etc. These requirements apply to all entities involved in payment card processing, including merchants, processors, and 3rd party service providers that store, process and transmit cardholder data. PCI DSS originally began as five different programs:

  • Visa’s Cardholder Information Security Program
  • MasterCard’s Site Data Protection
  • American Express’ Data Security Operating Policy
  • Discover’s Information Security and Compliance
  • JCB’s Data Security Program

The motive of the above listed companies was to protect the card holder by providing some guidelines to merchants or any other entity which is involved in storing, processing and transmitting cardholder data. From the above listed companies, a PCI Security Standards Council (SSC) was formed, and the first version of PCI DSS 1.0 was released in December 2004. Because of rapid changes in technology, new mode of payments, attack vectors, regulatory laws, etc., this version got back to back updates from 1.1 to 1.2. PCI subsequent versions 2.0 and 3.0 were released in October 2010 and November 2013 respectively.

One major theme that forms the basis of PCI-DSS 3.0, apart from some notable ones like education and awareness around payment security, increased flexibility to handle risks, and security as a shared responsibility, is to make PCI-DSS a Business As Usual (BAU) practice. The purpose of this document is to outlay the key drivers that led to PCI-DSS 3.0. Below are the key drivers and challenges that lead to PCI-DSS 3.0.

Lack of education and awareness around payment security

PCI DSS Encryption Requirements PCI Security Compliance PCI DSS Encryption PCI Compliance  PCI DSS Encryption PCI DSS: What You Need to Know

Due to lack of education and awareness around payment security, employees usually leave security holes in their developed applications by not following best security practices to code, picking up weak passwords, and sharing company information on public and social platforms. PCI-DSS 3.0 has incorporated requirements such as 8.4 that focus on personnel trainings, guidance around payment security, guidance for selecting and protecting authentication credentials, instructions to change passwords in case of any suspicion detected, etc.

The PCI-DSS council has gone a step ahead and also focuses on major sales points where card data is processed ie. POS terminal and brings these terminals under scope, as attacks on POS devices like cloning, addition of card skimmers, etc. are on a high. Requirement 9.9 which is to “Protect devices that capture card data via direct physical interaction with the card from tampering and substitution” is added to address the POS threat challenge. This requirement will now make organizations maintain an up-to date list of devices deployed at various sites. This list will contain information about POS devices such as:

  • Unique serial number of the device
  • Make and model of device
  • Location details at which it is deployed.

This requirement also focuses on providing training for end-personnel to be aware about the attempted tampering or replacement of authentic POS devices. Organizations need to conduct periodic reviews of devices to check for any evidence of substitution or tampering.

Third party security challenges

As per the security investigation report, 63 percent of security deficiencies that can result in breach or loss of cardholder data falls in the 3rd party IT landscape, whose business function is to process, transmit and store cardholder data received either from merchant or service providers. To handle crises whenever there is a breach resulting in cardholder data loss and no one to take ownership of that, PCI has added requirements 12.8, 12.9 to made it clear that both the engaging parties need to seal the deal with a written agreement, which should state a clear responsibility matrix. This requirement also requires the organization to do a proper due-diligence of the IT landscape, process, services offered, and security controls in place before entering into a formal agreement.

Along with the above stated requirement, PCI has also stated an additional requirement for service providers with requirement number 8.5.1 to maintain unique credentials for each customer when accessing their premises remotely for services like support of POS systems. This requirement will prevent the compromise of multiple customers’ account profiles in case the service provider used the same credentials for all the service providers and that in turn is compromised. Also service providers must set up strong credentials to access customer premises and should adopt best practice policies like a password change policy, etc.

Anti-malware solutions

The earlier PCI-DSS 2.0 standard specifies that there should be an antivirus solution deployed to protect the CDE environment from viruses, malware, etc. and that it should be completely updated with the latest patches and signatures, but the requirement did not specify about the access control settings over the AV software, such as access control over the AV manager, meaning who can only disable the AV solution and who can view its logs and edit the configuration changes. However in PCI-DSS 3.0, requirement 5.3 now requires organizations to deploy tighter policy based controls around antivirus solution that will require authorization to access and alter the configuration settings of the AV solution.

To keep controls deployment and maintenance costs in check, merchants generally come up with a classification of important endpoints that will be covered under security controls deployment like antivirus. Though asset classifications is a good practice, merchants do not generally update these lists with the ever-changing threat landscape. Keeping this in check, PCI-DSS has added a new requirement 5.1.2 which requires merchants to identify and evaluate evolving threats against systems which are not commonly affected by malicious software like mainframes, so as to develop a tighter antivirus security around all the systems in the CDE environment. Merchants can take guidance from vendors to understand the changing threat landscape and to evaluate whether their unprotected systems come under newly discovered vulnerabilities.

Penetration testing

One of the key drivers and significant changes in PCI-DSS 3.0 is addition of the requirement for merchants to conduct penetration testing on their cardholder environment. SSC has laid emphasis on the point that merchants/service providers must adopt an industry wide accepted penetration testing like NIST SP 800-15. PCI requirements also need to conduct penetration tests not only at the application level but also at the network level against devices that are deployed at the perimeter (say for segregation) or deployed inside CDE environment. PCI requirement 13.4 would require providers to conduct:

  • Annual penetration tests on the external network and when there is any significant change in infrastructure or applications deployed in CDE environment.
  • Annual penetration tests on the internal network and when there is any significant change in infrastructure or applications deployed in CDE environment.
  • Annual penetration tests on the boundary defense of CDE environment or around the segmentation controls that are used to isolate the CDE environment to check their effectiveness.
  • Adopt the cyclic process of Test (Conduct Penetration testing (PT)) > Remediate (Fix Vulnerabilities) > Re-Test (Conduct PT again) until all the vulnerabilities found are fixed.
  • Requires merchants/service providers to retain the Penetration testing results and remediation activities as per the adopted industry driven approach.

Inventory list

PCI has made it mandatory for retailers to maintain an inventory list of all the in-scope devices for CDE environment. With addition of requirement 2.4 which states, “Maintain an inventory of systems components that in scope of PCI DSS”, PCI made sure that retailers keep updating their inventory list with the already in action system components or to any newly added one. To avoid any confusion, PCI has also mentioned in some drilled down requirements what all needs to be put in the inventory list, such as:

  • Requirement no 11.1.1 states that “maintain an inventory of authorized wireless access points including a documented business justification ” will require retailers to maintain an inventory list for all access points with a proper business justification.
  • Requirement no 9.7.1 states that to “Properly maintain inventory logs of all media and conduct media inventories at least annually” will require retailers to maintain an inventory list of all the media so that stolen or missing media should not go unnoticed.
  • Requirement no 12.3.4 requires retailers to maintain an inventory of all physical devices with proper labeling to mark any unapproved installations.

However, the above stated requirement to maintain an inventory list will be very difficult for organizations to maintain until they fully practice the requirement no 1.1.3 which requires organizations to maintain an updated data flow diagram (DFD) to showcase all the controls that are in CDE environment. With an updated DFD, organizations will be able to classify what is in-scope and out of scope for their CDE environment.

Business as Usual (BaU)

One of the major themes of PCI-DSS 3.0 is to make it as a Business as Usual (BAU) Practice rather than compliance. As PCI-DSS covers a majority of mid-sized business that either do not have a large IT department or they have very few information security groups which can work to keep their business PCI-DSS-ready for audits and to incorporate any last minute hiccups. Making PCI-DSS as a BAU will require organizations to keep their PCI-DSS checklist updated regularly with any change in their CDE environment. Merchants should keep a check and document all the changes done in their cardholder data environment (CDE). These includes:

  • Regular monitoring of security controls like firewall, AV solutions, access controls, IDS/IPS, Security Incident and Event Management (SIEM), etc. in CDE environment to ensure that they are correct, updated and their functioning is secure.
  • Reviewing the security posture of the CDE environment with addition of new systems and devices, changes in configurations of security controls, organizational structure changes, etc.
  • Reviewing latest best practices, support issued by vendors for the security devices that are placed in CDE environment to make sure that the cardholder data is secured from evolving threats.

Conclusion

PCI-DSS 3.0 has incorporated some good new requirements as per the changing threat landscape, included the end user to understand about payment security, and clarified some statements for proper understanding of merchants and 3rd party service providers. Some of the changed requirements that are incorporated in PCI DSS 3.0 are termed as best practice for some time now, after which they will become mandatory for every organization to implement. PCI DSS 3.0 will surely make merchants, service providers or any entity that is processing, storing and transmitting cardholder data and is under PCI scope to revisit and enhance their existing strategy for protecting cardholder information.

References

https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf

Author Bio:
Lohit Mehta is a Security Researcher for the InfoSec Institute. He has experience working with RFPs/RFIs; Security HLD and LLD design; Network Security elements like Firewall, IDS/IPS, DLP, Reverse proxy, WAF; in Public Key Infrastructure(PKI); in Application Security testing for OWASP Top 10; in Compliance’s like PCI-DSS 2.0,3.0 , ISO 27k1, HIPPA; with Cloud Service Provider’s such as AWS; in Security Incident and Event Management(SIEM) with tools like Splunk; in Vulnerability Testing.

The post PCI DSS: What You Need to Know appeared first on Porticor Cloud Security.

More Stories By Gilad Parann-Nissany

Gilad Parann-Nissany, Founder and CEO at Porticor is a pioneer of Cloud Computing. He has built SaaS Clouds for medium and small enterprises at SAP (CTO Small Business); contributing to several SAP products and reaching more than 8 million users. Recently he has created a consumer Cloud at G.ho.st - a cloud operating system that delighted hundreds of thousands of users while providing browser-based and mobile access to data, people and a variety of cloud-based applications. He is now CEO of Porticor, a leader in Virtual Privacy and Cloud Security.

CloudEXPO Stories
Technology has changed tremendously in the last 20 years. From onion architectures to APIs to microservices to cloud and containers, the technology artifacts shipped by teams has changed. And that's not all - roles have changed too. Functional silos have been replaced by cross-functional teams, the skill sets people need to have has been redefined and the tools and approaches for how software is developed and delivered has transformed. When we move from highly defined rigid roles and systems to more fluid ones, we gain agility at the cost of control. But where do we want to keep control? How do we take advantage of all these new changes without losing the ability to efficiently develop and ship great software? And how should program and project managers adapt?
Even if your IT and support staff are well versed in agility and cloud technologies, it can be an uphill battle to establish a DevOps style culture - one where continuous improvement of both products and service delivery is expected and respected and all departments work together throughout a client or service engagement. As a service-oriented provider of cloud and data center technology, Green House Data sought to create more of a culture of innovation and continuous improvement, from our helpdesk on to our product development and cloud service teams. Learn how the Chief Executive team helped guide managers and staff towards this goal with metrics to measure progress, staff hiring or realignment, and new technologies and certifications.
When Enterprises started adopting Hadoop-based Big Data environments over the last ten years, they were mainly on-premise deployments. Organizations would spin up and manage large Hadoop clusters, where they would funnel exabytes or petabytes of unstructured data.However, over the last few years the economics of maintaining this enormous infrastructure compared with the elastic scalability of viable cloud options has changed this equation. The growth of cloud storage, cloud-managed big data environments, and cloud data warehouses like Snowflake, Redshift, BigQuery and Azure SQL DW, have given the cloud its own gravity - pulling data from existing environments. In this presentation we will discuss this transition, describe the challenges and solutions for creating the data flows necessary to move to cloud analytics, and provide real-world use-cases and benefits obtained through adop...
Docker and Kubernetes are key elements of modern cloud native deployment automations. After building your microservices, common practice is to create docker images and create YAML files to automate the deployment with Docker and Kubernetes. Writing these YAMLs, Dockerfile descriptors are really painful and error prone.Ballerina is a new cloud-native programing language which understands the architecture around it - the compiler is environment aware of microservices directly deployable into infrastructures like Docker and Kubernetes.
Your applications have evolved, your computing needs are changing, and your servers have become more and more dense. But your data center hasn't changed so you can't get the benefits of cheaper, better, smaller, faster... until now. Colovore is Silicon Valley's premier provider of high-density colocation solutions that are a perfect fit for companies operating modern, high-performance hardware. No other Bay Area colo provider can match our density, operating efficiency, and ease of scalability.