WHAT IS THE PAYMENT CARD INDUSTRY DATA SECURITY STANDARD (PCI DSS)

The PCI DSS document is a comprehensive standard that covers all aspects of handling and protecting credit cardholder data.

The standard requires all merchants to ensure that only authorized people have access to card data and that access uses strong authentication.

All businesses that receives credit card payments must comply with the PCI DSS cybersecurity rules or risk loosing the merchant rights.

The reader can download the PCI DSS documents from the PCI Document Library after first registering and providing contact information.

SUMMARY OF PCI DSS REQUIREMENTS TO IMPLEMENT A SECURE ENVIRONMENT FOR CARDHOLDER DATA

Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need to know (p.66)
7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access.
7.1.1 Define access needs for each role, including:
· System components and data resources that each role needs to environment. access for their job function.
· Level of privilege required (for example: user, administrator, etc.) for accessing resources.

Requirement 8: Identify and authenticate access to system components (p.69)
8.2.3 Password/pass-phrases must meet the following:
· Require a minimum length of at least seven characters.
· Contain both numeric and alphabetic characters.
Alternatively, the passwords/pass-phrases must have complexity and strength at least equivalent to the parameters specified above.
8.2.4 Change user passwords/pass-phrases at least once every 90 days.
8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication.

Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data (p.20)
1.2.3 Install perimeter firewalls between all wireless networks and the cardholder data environment, and configure these firewalls to deny or, if traffic is necessary for business purposes, permit only authorized traffic between the wireless environment and the cardholder data environment.

Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data. (p. 88)
10.1 Implement audit trails to link all access to system components to each individual user.
10.2 Implement automated audit trails for all system components to reconstruct the following events:
10.2.1 All individual user accesses to cardholder data.
10.2.2 All actions taken by any individual with root or administrative privileges.
10.2.3 Access to all audit trails.
10.2.4 Invalid logical access attempts.
10.3 Record at least the following audit trail entries for all system components for each event:
10.3.1 User identification.
10.3.2 Type of event.
10.3.3 Date and time.
10.3.4 Success or failure indication.
10.3.6 Identity or name of affected data, system component, or resource.

PROTECTED HEALTH INFORMATION (PHI)

All healthcare entities that hold Protected Health Information (PHI) must comply with the HIPAA law, specifically the Security Rule for cybersecurity compliance. This includes hospitals, clinics, insurers, pharmacies, etc.

If a healthcare entity suffers a cyber attack with a data breach then it is a requirement of the law that the incident is reported to the HHS. All incidents with over 500 PHI breaches are listed on the HHS data breach website. If after investigation the HHS finds that the healthcare entity is not in compliance with the HIPAA security rule then a fine will be imposed on the entity according to the number of PHI records breached.

A PHI data breach is any type of unauthorized access to a computer that holds Protected Health Information. The most frequent type of data breach is a ransomware attack.

The HIPAA security rule requires the entity to ensure that only authorized people have access to PHI and that PHI access uses a strong authentication method.

SUMMARY OF THE HIPAA SECURITY RULE

ACCESS CONTROL - §164.312(a)(1)
“Implement technical poiicies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in §164.208(a)(4).“

UNIQUE USER IDENTIFICATION - §164.312(a)(2)(i)
“Assign a unique name and/or number for identifying and tracking user identity.”

PERSON OR ENTITY AUTHENTICATION - §164.312(d)
“Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.”

AUTOMATIC LOGOFF - §164.312(a)(2)(iii)
“Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.”

EMERGENCY ACCESS PROCEDURE - §164.312(a)(2)(ii)
“Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.”

AUDIT CONTROLS - §164.312(b)
“Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

SUMMARY OF NIST CYBERSECURITY FRAMEWORK CORE FUNCTIONS

GOVERN (GV) – Establish and monitor the organization’s cybersecurity risk management strategy, expectations, and policy. The GOVERN Function informs how an organization will achieve and prioritize the outcomes of the other five Functions in the context of its mission and stakeholder expectations. Governance activities are critical for incorporating cybersecurity into an organization’s broader enterprise risk management strategy.

IDENTIFY (ID) – Help determine the current cybersecurity risk to the organization. Understanding its assets (e.g., data, hardware, software, systems, facilities, services, people) and the related cybersecurity risks enables an organization to identify gaps and prioritize its efforts in a manner consistent with its risk management strategy and the mission needs.

PROTECT (PR) – Use safeguards to prevent or reduce cybersecurity risk. Once assets and risks are identified and prioritized, PROTECT supports the ability to secure those assets to prevent or lower the likelihood and impact of adverse cybersecurity events.

DETECT (DE) – Find and analyze possible cybersecurity attacks and compromises. DETECT enables timely discovery and analysis of anomalies, indicators of compromise, and other potentially adverse cybersecurity events that may indicate that cybersecurity attacks and incidents are occurring.

RESPOND (RS) – Take action regarding a detected cybersecurity incident. RESPOND supports the ability to contain the impact of cybersecurity incidents. Outcomes within this Function cover incident management, analysis, mitigation, reporting, and communication.

RECOVER (RC) – Restore assets and operations that were impacted by a cybersecurity incident. RECOVER supports timely restoration of normal operations to reduce the impact of cybersecurity incidents and enable appropriate communication during recovery efforts.

The National Institute of Standards and Technology (NIST) researches and publishes reference documents for cybersecurity and Zero Trust. Click the buttons shown below to download relevant documents published by NIST.

SUMMARY OF THE SEVEN NIST TENETS OF ZERO TRUST

Tenet 1. All data sources and computing services are considered resources. A network may be composed of multiple classes of devices. A network may also have small footprint devices that send data to aggregators/storage, software as a service (SaaS), systems sending instructions to actuators, and other functions. An enterprise may classify personally owned devices as resources if they are allowed to access enterprise-owned resources.

Tenet 2. All communication is secured regardless of network location. Network location alone does not imply trust. Access requests from assets located on enterprise-owned network infrastructure (e.g., inside a legacy network perimeter) must meet the same security requirements as access requests and communication from any other non-enterprise-owned network. In other words, trust should not be automatically granted based on the device being on enterprise network infrastructure.

Tenet 3. Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before the access is granted. Access should also be granted with the least privileges needed to complete the task. Authentication and authorization to one resource will not automatically grant access to a different resource.

Tenet 4. Access to resources is determined by dynamic policy — including the observable state of client identity, application/service, and the requesting asset — and may include other behavioral and environmental attributes. For Zero Trust, client identity can include the user account (or service identity) and any associated attributes assigned by the enterprise to that account or artifacts to authenticate automated tasks.

Tenet 5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted. An enterprise implementing a ZTA should establish a continuous diagnostics and mitigation (CDM) or similar system to monitor the state of devices and applications and should apply patches/fixes as needed.

Tenet 6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. An enterprise implementing a ZTA would be expected to have Identity, Credential, and Access Management (ICAM) and asset management systems in place. This includes the use of multifactor authentication (MFA) for access to some or all enterprise resources.

Tenet 7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

INTRODUCTION TO THE GDPR

The EU’s General Data Protection Regulation (GDPR) law applies to personal data, (Personal Identifiable Information - PII), which is any piece of information that relates to an identifiable person. The GDPR clearly defines what is and is not personal data. The GDPR is strong enough to give individuals clear and tangible protection while being flexible enough to allow for the legitimate interests of businesses and the public.

‘Personal data’ means any information relating to an identified or identifiable person (‘data subject’); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

It is important that any business with EU consumers understands the requirements for GDPR compliance. If an organization collects, uses, or stores the personal data of citizens in the EU, then that organization must comply with the GDPR’s privacy and security requirements, even if that organization does not have a physical presence within the EU.

GDPR documents can be downloaded by clicking the buttons below.

CHAPTER IV: CONTROLLER AND PROCESSOR SECTION 1: GENERAL OBLIGATIONS

Article 25: Data protection by design and by default, paragraph 2.
“The controller (the company individual responsible for security of PII) shall implement appropriate technical and organizational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed.”

Article 30: Records of processing activities, paragraph 1.
“Each controller and, where applicable, the controller’s representative, shall maintain a record of processing activities under its responsibility.”

Article 30: Records of processing activities, paragraph 4.
“The controller or the processor and, where applicable, the controller's or the processor's representative, shall make the record available to the supervisory authority on request.”

CHAPTER IV: CONTROLLER AND PROCESSOR SECTION 2: SECURITY OF PERSONAL DATA

Article 32: Security of processing, paragraph 1.
“The controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk.”

Article 32: Security of processing, paragraph 4.
“The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller.”