Abstract- The European Union’s General Data Protection Regulation (EU GDPR) has ultimately taken an impact. Although businesses have had sufficient time to prepare, most of them may not be ready yet. PCI DSS and the GDPR overlap in some respects, they fluctuate in others – simply because a business enterprise is Payment Card Industry Data Security Standard (PCI DSS) compliant, it does not necessarily mean that it is compliant with the GDPR. However, U.S. companies that are already compliant with the PCI DSS which includes any business that handles payment card data will be anticipated to have some measures in place that will help direct them down the right path to GDPR compliance. With its numerous sub-requirements and potentially hundreds of controls, PCI DSS is one of the most complex industry-wide standards and is still probably the closest thing the U.S. has to a national data protection regulation. To help companies understand the differences and similarities among GDPR and PCI DSS, and what they can do to assist ease cross-compliance, we will be explaining this complex topic in more detail in this paper. Both the regulations are currently available only in the textual format and so requires significant manual effort to ensure its compliances. We have developed a semantically rich Ontology (or knowledge graph) to represent the rules and regulations mandated for both PCI DSS and EU GDPR. In the Ontology, we have identified corresponding obligations of two regulations and related them with CSA controls.
Keywords: Data Protection; Ontology; General Data Protection Regulation; Organizations.
1. INTRODUCTION
Broad adoption of Cloud services all over the world has resulted in large amount of Personally Identifiable Information (PII) being managed and transferred across the Internet. Organizations often use this data, with user’s permission, to provide an improved and seamless user experience and to enhance their businesses. They are also developing techniques by using advanced technologies like machine learning, natural language processing, deep learning techniques etc. for safe usage of their data assets. However, because of this cloud data explosion, regulatory bodies throughout the globe are releasing new data compliance laws that must be adhered to by Cloud Processors and consumers.
Both the PCI DSS and the GDPR purpose is to ensure that organizations secure personal data. PCI DSS mainly focuses on payment card and cardholder data, while the GDPR focuses on European resident’s personal data. The significant difference is that the GDPR is less narrow than the PCI DSS. GDPR and PCI DSS differ is in the type of data involved. The PCI DSS deals firmly with payment card data and cardholder information, such as debit/credit card numbers, primary account numbers (PAN), and sensitive authentication data (SAD) such as CVVs and magnetic stripe data, from all the major card schemes. The GDPR has a much broader scope and covers any PII. The type of data in the space for GDPR includes PII related to any EU resident, whether it is connected to his or her private, professional or public life. This can include a name, home address, photo, email address, bank details, medical information, posts on social networking websites, or a computer’s IP address. What’s important to understand here is that a breach that violates PCI DSS compliance also violates the GDPR. However, a breach that violates GDPR compliance does not necessarily violate the PCI DSS.
As both the regulation are currently available only in the textual format, it will require significant human and time effort to adhere to it. We have created a semantically rich policy-based knowledge representation of the PCI DSS and GDPR regulations with corresponding CSA controls. We used Semantic Web’s Web Ontology Language (OWL) to create this knowledge graph. Also, we have developed an ontological knowledge graph which is machine processable and so can contribute significantly in automating the continuous monitoring of data operation, transfer and sharing.
2. RELATED WORK
In the below sections, we will describe our previous work of GDPR, PCI DSS and usage of semantic web technology
2.1 GDPR
The key components of GDPR which have identified in our previous work are summarized and listed below:
Consumers and Processors:
The Regulation separates tasks and obligations of data consumers and Processors, obligating Consumers to engage only those processors that provide “sufficient guarantees to implement appropriate technical and organizational measures” to meet the Regulation’s requirements and protect data subject’s rights.
The regulation provides specific suggestions for what kinds of security actions might be considered “appropriate to the risk,” including:
● The pseudonymization and/or encryption of personal data.
We have gone through all the articles of consumers and Processors and summarized the obligations.
● The ability to ensure the ongoing confidentiality, integrity, availability and resilience of systems and services processing personal data.
● The ability to restore the availability and access to data in a timely manner in the event of a physical or technical incident.
● A process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing.
Fines and Enforcement:
Breach of compliance will result in fines of up to 4% of global revenue or €20m, equivalent to roughly $23.4m whichever is greater. It will dependent on the severity of the breach and the organization’s ability to demonstrate that there were initial measures in place (or not) to protect customer data.
Breach & Notification:
In the incident of a personal data breach data Consumers must inform the appropriate supervisory authority without undue delay and, where possible, not later than 72 hours after knowing about data breach. If notification is not made within 72 hours, the controller must provide a reasoned justification for the delay.
Data Protection Officer:
Whoever holds this position will be accountable for managing data protection and data privacy, and free to give approvals or feedback without any fear of negative implications. This only applies if an organization handles huge important volumes of data, typically not applicable to small to medium-sized enterprises.
Data Subject:
Individuals will have more information on how their data is handled and this information should be available in a clear and reasonable way. Consumers must inform subjects of the period (or reasons why) data will be reserved on collection. Should the data subject subsequently wish to have their data removed and the data is no longer required for the reasons for which it was collected then it must be erased.
Obligated Role
Description
Consumer
Consumer is mainly obligated to below regulations:
→Notify about Personal Data Breach to Supervisory Authority
→Communicating about personal breach to data subject
→Carry out Data Protection Impact assessment
→Consulting Supervisory Authority before processing if DPIA shows high risk
→Appointing Data Protection Officer while processing personal data on large scale
Provider Provider is mainly obligated to below regulations:
→Support consumer during data breaches
→Processing data as per consumer instructions
→Maintain records of all processing activities
→Provide sufficient data security to consumer
→Implement Privacy by Design / Default
→Assisting consumer in DPIAs review / for risk processing
→Removing all the personal data after end of provision
→Notify data consumer for subcontracting
→Cooperating with Supervisory Authority
→Comply with certification requirements
→Attain parental consent if any services are offered to a child
→Follow the requirements for appointing and acting as a DPO
→Fulfill with the data subject rights
→Comply with the rules while transferring the data outside EU
2.2 Semantic Web
Semantic web is a representation of the World Wide Web by providing standards to express relationships between web information. The Semantic Web deals primarily with data instead of documents. It enables data to be annotated with machine understandable meta-data, allowing the automation of their retrieval and their usage in correct contexts [1].
Semantic Web technologies include languages such as Resource Description Framework (RDF) and Web Ontology Language (OWL) for defining ontologies and describing meta-data using these ontologies as well as tools for reasoning over these descriptions [1][18]. These technologies can be used to provide common semantics of privacy information and policies enabling all agents who understand basic Semantic Web technologies to communicate and use each other’s data and Services effectively [1].
In one of our prior works, we described a new integrated methodology for the lifecycle of IT services delivered on the cloud and demonstrate how it can be used to represent and reason about services and service requirements and so automate service acquisition and consumption from the cloud [1] [18]. In this paper also, we are building a knowledge graph with the help semantic web technology[1].
2.3 PCI DSS
This section of our paper will describe the major key requirements, which are needed by any organizations in order to be PCI DSS compliant. The goal of the PCI DSS is to protect cardholder data wherever it is processed, stored or transmitted [1] [4]. The security controls and processes required by PCI DSS are vital for protecting cardholder account data, including the PAN – the primary account number printed on the front of a payment card. Merchants and any other service providers involved with payment card processing must never store sensitive authentication data after authorization [1] [4]. This includes sensitive data that is printed on a card or stored on a card’s magnetic stripe or chip – and personal identification numbers entered by the cardholder [1] [4]. Figure1 represents details on card of a cardholder.
Figure 1: Data on Payment card (Payment Card Industry Security Standards Council, 2016) [1] [4]
In general, if an organization deals in card transactions then it must follow the key policies listed in the sections below. The PCI Data Security Standard specifies twelve requirements for compliance, organized into six logically related groups [1] [4]. These policies are part of latest PCI DSS Version 3.2 released in 2016 [1] [4]. These 6 groups that hold all the generic 12 requirements are described below.
1 Build and maintain a Secure Network
‘Install and maintain a firewall configuration to protect cardholder data [1][4]’. The network configuration and its security requirements should be the shared by the IT team and cloud service providers [1] [4]. ‘Define system password and its security parameters’ [1][4]. This means that all the default passwords supplied by the providers should be changed when a system is getting installed in the configured network [1][4].
2 Protect Cardholder Data
‘Protect stored cardholder data’ [1] [4]. This means that only necessary data should be stored and at least every quarter any unnecessary data should be purges. PAN details should be masked, the first six and last four digits are the maximum number of digits you may display [1] [4]. Also, PAN details must be made unreadable wherever it is being stored [1] [4].‘Encrypt transmission of cardholder data across open, public networks’ [1] [4]. This rule of PCI DSS policy asks the organization to make use of strong cryptography and encryption technologies like SL/TLS, SSH or IPSec etc. inorder to safeguard sensitive cardholder data during transmission over any networks [1] [4].
3 Maintain a Vulnerability Management Program
‘Us and regularly update anti-virus software or programs’ [1] [4]. All the systems and servers should have anti-virus software’s to prevent malicious activity. At the same time, anti-virus services should be running in the background and generating auditing logs [1] [4].‘Develop and maintain secure systems and applications’ [1] [4]. This policy ensures that all the patches mut be installed on time whenever any new patches are published by the vendors [1][4]. Any changes to the system components, coding of applications must be done through proper change and control procedures [1] [4]. Also, firewall protection should be ensured for any public facing web applications [1] [4].
Figure 2: PCI DSS Requirements (Payment Card Industry Security Standards Council, 2016) [1] [4]
4 Implement Strong Access Control Measures
‘Restrict access to cardholder data by business need to know’ [1] [4]. This policy ensures that the access is limited to system components and cardholder’s data. Also, an access control protocol for systems components should be in place for multiple users and it must restrict access based on a user’s needs and should be set to “deny all” unless specifically authorized [1] [4]. ‘Assign a unique ID to each person with computer access’. These policies ensure that any person who is accessing the data should have a unique ID [4]. This will help in tracing an individual’s activity in case of any violation or misuse [4]. Also, there should be a two-factor authentication for remotely logging into the network for, such as making use of RSA token or other technologies that facilitate two-factor authentication [1] [4]‘. Restrict physical access to cardholder data’ [1][4]. This ensures that proper facility controls should be applied to the cardholder data environment and individual only with proper authorization should be allowed to access cardholder’s data [1][4]. For visitors, proper token should be given with an expiry and a visitor log must be maintained for tracking purposes [1] [4].
5 Regularly Monitor and Test Networks
‘Track and monitor all access to network resources and cardholder data’ [1][4]. This ensures that an established process should be implemented to link access of individuals to system components [1][4]. Log activities of the system components must be reviewed daily, and audit trail history must be retained for at least one year so that three months of activity is available immediately [1][4]. ‘Regularly test security systems and processes’ [1][4]. This ensures that all the test procedures should be in place to detect access points and unauthorized users [1][4]. Also, external and internal penetration testing should be performed, including network and application-layer penetration tests at least annually [1][4].
6 Maintain an Information Security Policy
‘Maintain a policy that addresses information security for all personnel’ [1][4]. This ensures that the PCI DSS policies that has been established, published, maintained has descriptive clear definitions of the procedures that everyone in the system knows thoroughly; and such policy must be reviewed at least once a year [1][4].
3. METHODOLOGY
4. CONCLUSION & FUTURE WORK
In this work we have organized the ontology for two main objectives. First, to emphasize the obligations that data controller and processor should be in compliance from May 2018. Second, Consumers or processors will have well-defined view and they can use above articles as check list to find if they have met the obligations.
The ontology which we have designed is the initial step to the long-term goal of verifying compliance with GDPR. In our future research we want to research the security aspects and relate to this.
5. REFERENCES
[1] A. Nagar and K. P. Joshi, “A Semantically Rich Knowledge Representation of PCI DSS for Cloud Services”, In Proceedings, 6th International IBM Cloud Academy Conference ICACON 2018, Japan, May 2018, 68 downloads.
[2] Srishty Saha, Karuna P. Joshi, Renee Frank, Michael Aebig, Jiayong Lin. Automated Knowledge Extraction from the Federal Acquisition Regulations System (FARS). InProceedings, IEEE International
[3] Karuna Pande Joshi et al., “Automating Cloud Services Lifecycle through Semantic technologies”, Article, IEEE Transactions on Service Computing, January 2014,
[4] Payment Card Industry (PCI) Data Security Standard, Version 3.2 April 2016
[5] Suman Ramkhelawan, Baby Gobin-Rahimbux, Zarine Cadersaib. PCI-DSS Requirements in the Mauritian Hospitality Industry. In proceedings, IEEE International Conference EmergiTech, 2016
[6] D. McGuinness, F. Van Harmelen, et al., OWL web ontology language overview, W3C recommendation, World Wide Web Consortium, 2004.
[7] Natalya F, D. McGuinness, Ontology Development 101: A Guide to Creating Your First Ontology, 2004
[8] Ontology for Cloud Services SLA (Service Level Agreement), Karuna Pande Joshi and Tim Finin https://ebiquity.umbc.edu/resource/html/id/344/Ontology-for-Cloud-Services-SLA-Service-Level-Agreement
[9] S. Mittal, K. P. Joshi, C. Pearce, and A. Joshi, “Automatic Extraction of Metrics from SLAs for Cloud Service Management”, InProceedings, 2016 IEEE International Conference on Cloud Engineering (IC2E 2016), 2016
[10] Apache Jena Fuseki Server, https://jena.apache.org/documentation/fuseki2/
[11] Getting started with RDF SPARQL queries and inference using Apache Jena Fuseki, Christine Draper, https://christinemdraper.wordpress.com/2017/04/09/getting-started-with-rdf-sparql-jena-fuseki/
[12] OWL: Web Ontology Language, Sean Bechhofer, https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_1073
[13] S. Soderland, Learning to extract text-based information from the world wide web, in KDD, vol. 97, 1997, pp. 251254
[14] Understanding the 12 Requirements of PCI DSS -Practical steps to achieve and maintain compliance, Opinion Piece [Online]. www.dimensiondata.com/globalpresence. [Accessed: 21- Feb- 2016]
[15] Meeting PCI DSS When Using a Cloud Service Provide – ISACA , http://www.isaca.org
[16] K. P. Joshi and C. Pearce, “Automating Cloud Service Level Agreements Using Semantic Technologies,” 2015 IEEE International Conference on Cloud Engineering, Tempe, AZ,2015, pp. 416-421, doi: 10.1109/IC2E.2015.63
[17]Protégé Editor- Protégé Tool
http://protege.stanford.edu.
[18] Karuna P Joshi, Aditi Gupta, Sudip Mittal, Claudia Pearce, Anupam Joshi, and Tim Finin. Semantic Approach to Automating Management of Big Data Privacy Policies. In Proceedings, IEEE BigData, 2016.