Month: May 2022

PCI DSS V4.0 Core 12 Requirements – Part 2

Posted on by admin

PCI DSS 4.0 Requirement 7 –  Requirement  12 covers multiple aspects, like restriction on the cardholder data, network and user access, testing of ongoing systems and how organizations maintain their infosec policy.

Requirement 7 : Restrict Access to System Components and Cardholder Data by Business Need to Know

  • Organizations needs to establish a robust Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood
  • Access to system components and data is appropriately defined and assigned
  • Access to system components and data is managed via an access control system(s).

Requirement 8 : Identify Users and Authenticate Access to System Components

  1. Organizations needs to establish a robust Processes and mechanisms for identifying users and authenticating access to system components are defined and understood
  2. User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle
  3. Strong authentication for users and administrators is established and managed
  4. Organization must enforce multi-factor authentication (MFA) is implemented to secure access into the CDE
  5. Organization must enforce multi-factor authentication (MFA) systems are configured to prevent any misuse.
  6. Use of application and system accounts and associated authentication factors is strictly managed.

Requirement 9 : Restrict Physical Access to Cardholder Data

  1. Organizations needs to establish a robust Processes and mechanisms for restricting physical access to cardholder data are defined and understood.
  2. Physical access controls manage entry into facilities and systems containing cardholder data.
  3. Physical access for personnel and visitors is authorized and managed.
  4. Media with cardholder data is securely stored, accessed, distributed, and destroyed.
  5. Point of interaction (POI) devices are protected from tampering and unauthorized substitution

Requirement 10 : Log and Monitor All Access to System Components and Cardholder Data

  1. Organizations needs to establish a robust Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented.
  2. Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
  3. Audit logs are protected from destruction and unauthorized modifications.
  4. Audit logs are reviewed to identify anomalies or suspicious activity.
  5. Audit log history is retained and available for analysis.
  6. Time-synchronization mechanisms support consistent time settings across all systems.
  7. Failures of critical security control systems are detected, reported, and responded to promptly.

Requirement 11 : Test Security of Systems and Networks Regularly

  1. Organizations needs to establish a robust Processes and mechanisms for regularly testing security of systems and networks are defined and understood.
  2. Wireless access points are identified and monitored, and unauthorized wireless access points are addressed.
  3. External and internal vulnerabilities are regularly identified, prioritized, and addressed
  4. External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected
  5. Network intrusions and unexpected file changes are detected and responded to.
  6. Unauthorized changes on payment pages are detected and responded to.

Requirement 12 : Support Information Security with Organizational Policies and Programs

A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known.

  1. Acceptable use policies for end-user technologies are defined and implemented
  2. Risks to the cardholder data environment are formally identified, evaluated, and managed.
  3. PCI DSS compliance is managed
  4. PCI DSS scope is documented and validated
  5. Security awareness education is an ongoing activity
  6. Personnel are screened to reduce risks from insider threats
  7. Risk to information assets associated with third-party service provider (TPSP) relationships is managed
  8. Third-party service providers (TPSPs) support their customers’ PCI DSS compliance
  9. Suspected and confirmed security incidents that could impact the CDE are responded to immediately

Stay Tuned, for more information and updates on payment security !!

PCI DSS v4.0 Core 12 Requirements – Part 1

Posted on by admin

The PCI  Standards Security Council (PCI SSC) published the latest update to the PCI DSS v4.0 that has significantly shifted the focus on outcome-based. requirements. The core 12 PCI DSS requirements remained unchanged fundamentally with the revised version, however they are now realigned to significantly address how the security controls should be implemented.

PCI DSS v4.0 includes a number of changes and option to implement and validate PCI DSS requirements.

Requirement 1 : Install and Maintain Network Security Controls – Such as Firewalls and any other Network security Technologies such as VPC’s, Security Groups helps the entities to control the traffic between In/Out of their network and Internal network Segments physically or logically.

  1. Organizations needs to establish a robust Processes and mechanisms for installing and maintaining network security controls should be defined and communicate with all the stakeholders.
  2. Network security controls (NSCs) should be securely configured and maintained regularly.
  3. Network access to and from the cardholder data environment is restricted with predefined rules and policies.
  4. Network connections between trusted and untrusted networks are controlled.
  5. Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

Requirement 2 : Apply Secure Configurations to All System Components like Firewalls, Routers, Switches, Applications, Databases and any other Network security devices, End User devices etc.,

  1. Organizations needs to establish a robust Processes and mechanisms for applying secure configurations to all system components are defined and understood.
  2. System components are configured securely and managed securely.
  3. If organization using any Wireless environments, then such environments are configured and managed securely.

Requirement 3 : Protect Stored Account Data Like Card Holder Data (CHD) and Sensitive Authentication Data (CHD). Read our FAQ’s.

  1. Organizations needs to establish a robust Processes and mechanisms for protecting stored account data are defined and understood.
  2. Storage of account data is kept to a minimum as per the business and regulatory requirements.
  3. Sensitive authentication data (SAD) is not stored after authorization even if it is encrypted.
  4. Access to displays of full PAN and ability to copy cardholder data are restricted.
  5. Primary account number (PAN) is secured wherever it is stored.
  6. Cryptographic keys used to protect stored account data are secured.

Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

Requirement 4 : Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Network.

  1. Organizations needs to establish a robust Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.
  2. PAN is protected with strong cryptography during transmission.

Requirement 5 : Protect All Systems and Networks from Malicious Software like viruses, worms, Trojans, spyware, and rootkits etc.,

  1. Organizations needs to establish a robust Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.
  2. Malicious software (malware) is prevented or detected and addressed.
  3. Anti-malware mechanisms and processes are active, maintained, and monitored.
  4. Anti-phishing mechanisms protect users against phishing attacks.

Requirement 6 : Develop and Maintain Secure Systems and Software

  1. Organizations needs to establish a robust Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.
  2. Bespoke and custom software are developed securely.
  3. Security vulnerabilities are identified and addressed in timely manner
  4. Public-facing web applications are protected against attacks like Man-In Middle attacks etc.,
  5. Changes to all system components are managed securely

Read about the  PCI DSS 4.0 Core 12 Requirements – Part 2, here

Overview of Various PCI SSC Security Standards

Posted on by admin

PCI SSC maintains various PCI standards, supporting programs, and related documentation. PCI Security Standards are developed specifically to protect payment account data throughout the payment lifecycle.

  1. PCI DSS (Payment Card Industry Data Security Standard) : PCI DSS covers security of the environments that store, process, or transmit account data. The scope of PCI DSS covers environments receiving account data from payment applications and other sources—acquirers. Generally applicable for merchants, Service Providers, any payment solution providers.
  2. PCI Secure Software Standard ( 3S) : The Secure Software Standard defines a set of security requirements to help ensure payment software adequately protects the integrity and confidentiality of payment transactions and data. The Secure Software Standard includes a set of “core” requirements that apply to all types of payment software submitted for validation under the PCI Software Security Framework, regardless of the software’s functionality or underlying technology. Generally applicable for Payment Software vendors who would like to sell their Payment Software to their customers as a off the shelf-product.
  3. PCI Secure Software Lifecycle: The PCI Secure Software Lifecycle (Secure SLC) Requirements provides a baseline and guidance to help payment software design, develop, and maintain secure payment software throughout the software lifecycle. Generally applicable for Software Development vendors who would like to develop payment software on behalf of their customers.
  4. PCI 3DS ( Three Domain Secure): This standard helps the entities who perform the 3DS Server (3DSS), 3DS Directory Server (DS), 3DS Access Control Server (ACS) Functions.   3DS is a messaging protocol that enables end users to do a multi factor authentication themselves with their card issuer when making any online purchases / E-commerce Transactions. Generally applicable for Acquirers (Merchant Banks) and Issuers (Cardholders Bank).
  5. PA DSS (Payment Application Data Security Standard): PCI PA-DSS covers secure payment applications to support PCI DSS compliance. The scope of PA-DSS addresses when a payment application receives account data from cardholder-interface devices such as point-of-sale terminals or other devices and begins the payment transaction. However PA-DSS is replaced by PCI Software Security Framework. Generally applicable for Payment Application vendors who would like to sell their application as a off the shelf product.
  6. PCI PTS – POI (Payment Card Industry PIN Transaction Security Point of Interaction): The PCI PTS – POI standard covers device tamper detection, cryptographic processes, and other mechanisms used to protect the PIN and other sensitive data, such as cryptographic keys. Generally applicable for Device Manufacturers.
  7. PCI PTS – PIN ( Payment Card Industry PIN Transaction Security – Personal Identification Number: The PCI PTS – PIN standard covers secure management, processing and transmission of personal identification number (PIN) data during online and offline payment card transaction processing. Generally applicable for Device Manufacturers.
  8. PCI PTS – HSM ( Payment Card Industry PIN Transaction Security – Hardware Security Module): The PCI PTS – HSM standard covers the design of hardware security modules and for securely protecting those devices until they are deployed. Generally applicable for HSM Device Manufacturers.
  9. PCI P2PE (Payment Card Industry Point-to-Point Encryption) : PCI P2PE (Point-to-Point Encryption) covers secure encryption, decryption, and key management for point-to-point encryption solutions. Requirements for a P2PE solution will vary depending on the deployment environment and the technologies used for a specific implementation. Generally applicable for the service providers who are providing end to end encryption solutions for their merchants.
  10. PCI Contactless Payments on COTS ( CPoC): The PCI Contactless Payments on COTS (CPoC) Solutions enable contactless payment acceptance on a merchant’s consumer device using an embedded (near-field communications) NFC interface. This listing is a resource for merchants and acquirers to use in selecting a Contactless Payments on COTS (CPoC) Solutions. Generally applicable for PIN on Mobile Solution providers.
  11. PCI Software-Based PIN Entry on COTS (SPoC) : Also famous as PIN on mobile device. This Standard provides requirements for developing secure solutions that enable EMV contact and contactless transactions with PIN entry on the mobile devices of consumers using a secure PIN entry application in combination with a Secure Card Reader for PIN (SCRP). Generally applicable for PIN on Mobile Solution providers.

Stay Tuned, for more information and updates on payment security !!

Understanding HIPAA Rules In Brief

Posted on by admin

HIPAA provides guidance for the proper uses and disclosures of protected health information (PHI), how to secure PHI, and the response activities in case there is a breach. The HIPAA rules and regulations consists of five major components

  • HIPAA Security Rule
  • HIPAA Privacy Rule
  • HIPAA Omnibus Rule
  • HIPAA Breach Notification Rule
  • HIPAA Enforcement Rule

A summary of these Rules is discussed below.

HIPAA Security Rule:
The HIPAA Security Rule establishes national standards to protect individuals’ electronic personal health information that is created, received, used, or maintained by a covered entity. The Security Rule requires appropriate technical, physical and administrative safeguards to ensure the confidentiality, integrity, and security of electronic protected health information.

Technical Safeguards

Technical Safeguards concern the technology that is used to protect ePHI and provide access to the data. The only stipulation is that ePHI – whether at rest or in transit, it must be encrypted once it travels beyond an organization´s internal firewalled servers. This is so that any breach of confidential patient data renders the data unreadable, undecipherable, and unusable. Thereafter organizations are free to select whichever mechanisms are most appropriate to:

Physical Safeguards

Physical Safeguards focus on physical access to ePHI irrespective of its location. ePHI could be stored in a remote data center, in the cloud, or on servers which are located within the premises of the HIPAA covered entity. They also stipulate how workstations and mobile devices should be secured against unauthorized access:

HIPAA Administrative Safeguards

The Administrative Safeguards are the policies and procedures which bring the Privacy Rule and the Security Rule together. They are the pivotal elements of a HIPAA compliance checklist and require that a Security Officer and a Privacy Officer be assigned to put the measures in place to protect ePHI, while they also govern the conduct of the workforce.

HIPAA Privacy Rule

  • The HIPAA Privacy Rule governs how ePHI can be used and disclosed. In force since 2003, the Privacy Rule applies to all healthcare organizations, the providers of health plans (including employers), healthcare clearing houses and – from 2013 – the Business Associates of covered entities.
  • The Privacy Rule demands that appropriate safeguards are implemented to protect the privacy of Personal Health Information. It also sets limits and conditions on the use and disclosure of that information without patient authorization. The Rule also gives patients – or their nominated representatives – rights over their health information including the right to obtain a copy of their health records – or examine them – and the ability to request corrections if necessary.
  • Under the Privacy Rule, covered entities are required to respond to patient access requests within 30 days. Notices of Privacy Practices (NPPs) must also be issued to advise patients and plan members of the circumstances under which their data will be used or shared.

HIPAA Omnibus Rule:

HHS enacted the  final Omnibus Rule  in 2013 to address policy gaps in earlier HIPAA rules. Most notably, the Omnibus Rule defines the role of business associates, which were not previously subject to HIPAA rules, and outlines the criteria for Business Associate Agreements (BAAs) which must be executed between organizations sharing PHI before any information is transferred, handled, or maintained.

HIPAA Breach Notification Rule

The HIPAA Breach Notification Rule requires covered entities to notify patients when there is a breach of their ePHI. The Breach Notification Rule also requires entities to promptly notify the Department of Health and Human Services of such a breach of ePHI and issue a notice to the media if the breach affects more than five hundred patients.

There is also a requirement to report smaller breaches – those affecting fewer than 500 individuals – via the OCR web portal. These smaller breach reports should ideally be made once the initial investigation has been conducted. The OCR only requires these reports to be made annually.

Breach notifications should include the following information:

  • The  nature of the ePHI involved, including the types of personal identifiers exposed.
  • The unauthorized person who used the ePHI  or to whom the disclosure was made (if known).
  • Whether the ePHI was actually  acquired or viewed  (if known).
  • The extent to which the  risk of damage has been mitigated.

HIPAA Enforcement Rule

HIPAA Enforcement Rule governs the investigations that follow a breach of ePHI, the penalties that could be imposed on covered entities responsible for an avoidable breach of ePHI and the procedures for hearings. Although not part of a HIPAA compliance checklist, covered entities should be aware of the following penalties:

  • A violation attributable to ignorance can attract a fine of $100 – $50,000.
  • A violation which occurred despite reasonable vigilance can attract a fine of $1,000 – $50,000.
  • A violation due to willful neglect which is corrected within thirty days will attract a fine of between $10,000 and $50,000.
  • A violation due to willful neglect which is not corrected within thirty days will attract the maximum fine of $50,000.
  • Fines are imposed per violation category and reflect the number of records exposed in a breach, risk posed by the exposure of that data and the level of negligence involved.
  • Penalties can easily reach the maximum fine of $1,500,000 per year, per violation category. It should also be noted that the penalties for willful neglect can also lead to criminal charges being filed.
  • Civil lawsuits for damages can also be filed by victims of a breach.

The organizations most commonly subject to enforcement action are private medical practices (solo doctors or dentists, group practices, and so on), hospitals,  outpatient facilities such as pain clinics or rehabilitation centers, insurance groups, and pharmacies.

Need more insights ?  Get in touch  with our experts for any queries on HIPAA Assessment and Compliance.