Navigating Global Data Protection Compliance: Frameworks, Regulations, and Implementation Strategies

#

Introduction

#

In the recent weeks there has been some data breaches. To ensure compliance there are various regulatory compliance that ensure data is protected . Part of cybersecurity assessment service involves evaluating a client’s adherence to relevant compliance frameworks. This is no small responsibility, as failure to meet compliance requirements can result in heavy penalties. In some cases, our client might even be banned from doing business in certain countries due to non-compliance.

Take our client ABC , for example. They collect customer information as part of their business operations in Kenya, the EU, and the US. Additionally, they handle credit card transactions for purchases made through their online storefront. This means that client ABC must comply with frameworks such as GDPR and PCI DSS, among others.

While we’re on the topic of legal considerations, it’s important to familiarize ourselves with features of our customer agreements. These include contracts, service-level agreements (SLAs), confidentiality requirements, master service agreements (MSAs), and statements of work (SOWs). Understanding these agreements and how they affect our practice is essential for delivering high-quality services. Before performing any audit we ensure that all the legal compliance are in place. This is to prtoect us and the client.

Regulatory Compliance Considerations

#

To succeed in ethical hacking and penetration testing, you must be familiar with several regulatory compliance considerations. This knowledge is not only necessary for completing compliance-based assessments but also for understanding the regulations that may impact both you and your client.

Let’s start by assuming that you’ve been hired to perform a compliance-based assessment. In this scenario, you, as the penetration tester, are responsible for verifying and auditing the security posture of the organization. Your goal is to ensure that the organization complies with specific regulations, such as the following:

PCI DSS

#

The Payment Card Industry Data Security Standard (PCI DSS) regulation aims to secure the processing of credit card payments and other types of digital payments. You can access PCI DSS specifications, documentation, and resources at pcisecuritystandards.org.

HIPAA

#

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) was originally designed to simplify and standardize healthcare administrative processes. This involved transitioning from paper records and transactions to electronic records and transactions. The U.S. Department of Health and Human Services (HHS) was tasked with developing and publishing standards to protect an individual’s electronic health information while allowing appropriate access and use by healthcare providers and other entities. For more information about HIPAA, visit https://www.cdc.gov/phlp/publications/topic/hipaa.html.

Often, these regulations require companies to hire third-party penetration testing firms to ensure compliance and security. Familiarity with these regulations is key if you’re performing penetration tests to verify compliance and overall security. Many standards provide checklists for assessments.

You should also become familiar with privacy-related regulations, such as the General Data Protection Regulation (GDPR). GDPR includes strict rules around data processing and privacy. One of its primary goals is to strengthen and unify data protection for individuals within the European Union (EU), while addressing the export of personal data outside the EU. Essentially, the main objective of GDPR is to give citizens control over their personal data. Additional information about GDPR can be found at gdpr-info.eu .

To effectively complete a compliance-based assessment, you should familiarize yourself with some of the key underlying regulations, such as those described in the following sections.

Regulations in the Financial Sector

#

💰

International context (USA) Financial services institutions, such as banks, credit unions, and lending institutions, offer a wide range of solutions and financial instruments. While you might think that money is their most valuable asset, in reality, customer and transactional information is the heart of their business. Financial assets are material and can be replaced, but protecting customer information is crucial for establishing and maintaining trust between a financial institution and the community it serves. More specifically, institutions have a responsibility to safeguard the privacy of individual consumers and protect them from harm, including fraud and identity theft. On a broader scale, the industry is responsible for maintaining the critical infrastructure of the nation’s financial services.

Here are a few examples of regulations applicable to the financial sector:

• Title V, Section 501(b) of the Gramm-Leach-Bliley Act (GLBA) and the corresponding interagency guidelines
• The Federal Financial Institutions Examination Council (FFIEC)
• The Federal Deposit Insurance Corporation (FDIC) Safeguards Act and Financial Institutions Letters (FILs)

Compliance with some regulations, such GLBA, is mandatory.

GLBA defines a financial institution as “any institution the business of which is significantly engaged in financial activities . GLBA applies to all financial services organizations, regardless of size. This definition is important because it includes many companies that are not traditionally considered financial institutions. The law also applies to companies that receive information about customers of other financial institutions, including credit reporting agencies and ATM operators.

Regulations in the Financial Sector

#

💰 Kenyan context

In the Kenyan context, there are specific regulations that ensure data protection, privacy, and operational integrity. In the financial sector, key regulations include the Central Bank of Kenya (CBK) Prudential Guidelines, which mandate cybersecurity measures and risk management frameworks for banks and financial institutions. Additionally, the Data Protection Act (2019) aligns with global standards like GDPR, requiring financial institutions to safeguard customer data and ensure compliance with data privacy principles. Non-compliance can result in hefty penalties or restrictions on operations. Another critical regulation is the Capital Markets Authority (CMA) Cybersecurity Guidelines, which focus on protecting digital transactions and investor information in capital markets. These frameworks collectively emphasize the need for robust penetration testing, vulnerability assessments, and adherence to security standards.

Regulations in the Healthcare Sector

#

🩺

In the healthcare sector, the Kenya Health Information System Policy and the Data Protection Act (2019) play pivotal roles in safeguarding patient information and ensuring secure electronic health records (EHR). Healthcare providers must adhere to strict confidentiality requirements when handling personally identifiable health information (PIIHI), similar to HIPAA in the U.S. but tailored to local needs. Furthermore, the Health Act (2017) mandates the protection of patient rights, including data privacy, and requires healthcare facilities to implement technical and administrative safeguards. Compliance with these regulations is crucial for maintaining trust and avoiding legal repercussions. Together, these frameworks highlight the importance of securing sensitive data and ensuring the healthcare organizations in Kenya maintain a strong security posture to mitigate risks .

Payment Card Industry Data Security Standard (PCI DSS)

#

To protect cardholders against misuse of their personal information and minimize payment card channel losses, the major payment card brands (Visa, MasterCard, Discover, and American Express) formed the Payment Card Industry Security Standards Council (PCI SSC) and developed the Payment Card Industry Data Security Standard (PCI DSS). The latest version of the standard and collateral documentation can be obtained at pcisecuritystandards.org .

PCI DSS must be adopted by any organization that transmits, processes, or stores payment card data or that directly or indirectly affects the security of cardholder data. Any organization that leverages a third party to manage cardholder data has the full responsibility of ensuring that this third party is compliant with PCI DSS. The payment card brands can levy fines and penalties against organizations that do not comply with the requirements and/or can revoke their authorization to accept payment cards.

Before we proceed with details about how to protect cardholder data and guidance on how to perform penetration testing in PCI environments, we must define several key terms that are used in this module and are defined by the PCI SSC at pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf. Let’s explore each term:

Acquirer Also referred to as an “acquiring bank” or an “acquiring financial institution,” an entity that initiates and maintains relationships with merchants for the acceptance of payment cards. ASV (Approved Scanning Vendor) An organization approved by the PCI SSC to conduct external vulnerability scanning services.

Merchant For the purposes of PCI DSS, an entity that accepts payment cards bearing the logos of any of the members of PCI SSC (American Express, Discover, MasterCard, or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards for goods and/or services can also be a service provider if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly service. PAN (Primary Account Number) A payment card number that is up to 19 digits long.

Payment Brand Brands such as Visa, MasterCard, Amex, or Discover.

PCI Forensic Investigator (PFI) A person trained and certified to investigate and contain information about cybersecurity incidents and breaches involving cardholder data.

Qualified Security Assessor (QSA) An individual trained and certified to carry out PCI DSS compliance assessments.

Service Provider A business entity that is not a payment brand and that is directly involved in the processing, storage, or transmission of cardholder data. This includes companies that provide services that control or could impact the security of cardholder data, such as managed service providers that provide managed firewalls, intrusion detection, and other services, and hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.

To counter the potential for staggering losses, the payment card brands contractually require that all organizations that store, process, or transmit cardholder data and/or sensitive authentication data comply with PCI DSS. PCI DSS requirements apply to all system components where account data is stored, processed, or transmitted.

Account data consists of cardholder data as well as sensitive authentication data. A system component is any network component, server, or application that is included in, or connected to, the cardholder data environment. The cardholder data environment is defined as the people, processes, and technology that handle cardholder data or sensitive authentication data.

The PAN is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements apply if the PAN is stored, processed, or transmitted. If the PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. If cardholder name, service code, and/or expiration date are stored, processed, or transmitted with the PAN or are otherwise present in the cardholder data environment, they too must be protected. Per the standards, the PAN must be stored in an unreadable (encrypted) format. Sensitive authentication data may never be stored post-authorization, even if encrypted.

The PCI SSC website provides great guidance on the requirements for penetration testing. See pcisecuritystandards.org.

Key Technical Elements in Regulations to Consider

#

Most regulations dictate several key elements, and a penetration tester should pay attention to and verify them during assessments to ensure the organization is compliant. Let’s explore each element:

Data Isolation

#

Organizations that need to comply with PCI DSS (and other regulations, for that matter) should have a data isolation strategy. Also known as network isolation or network segmentation, the goal is to implement a completely isolated network that includes all systems involved in payment card processing.

Password Management

#

Most regulations mandate solid password management strategies. For example, organizations must not use vendor-supplied defaults for system passwords and security parameters. This requirement also extends far beyond its title and enters the realm of configuration management. In addition, most of these regulations mandate specific implementation standards, including password length, password complexity, and session timeout, as well as the use of multifactor authentication.

Key Management

#

Where data is encrypted ,the cryptographic key needs good management. Key management policy and standards should include assigned responsibility for key management, the nature of information to be protected, the classes of threats, the cryptographic protection mechanisms to be used, and the protection requirements for the key and associated processes. to get more guidanceon this you can consider visiting https://csrc.nist.gov/projects/key-management/key-management-guidelines

TIP: Your customer might have specific corporate policies that need to be taken into consideration when performing a penetration test. In most cases, the customer will initially disclose in its corporate policy any items that might have a direct impact on the penetration testing engagement, but you should always ask and clearly document whether there are any. Some companies might also be under specific regulations that require them to create vulnerability and penetration testing policies. These regulations might specify restricted and nonrestricted systems and information on how a penetration test should be conducted according to a regulatory standard.

During your pre-engagement tasks, you should identify testing constraints, including tool restrictions. Often, you will be constrained by certain aspects of the business and the technology in the organization . In addition, the following are a few examples of constraints that you might face during an audit or penetration testing engagement:

• Certain areas and technologies that cannot be tested due to operational limitations.
• Technologies that might be specific to the organization being tested
• Limitation of known exploits
• Systems that are categorized as out of scope because of their criticality or known performance problems

You should clearly communicate any technical constraints with the appropriate stakeholders of the organization that hired you prior to and during the testing.

Legal Scope during audit and pentesting.

#

The following are several important legal concepts that you must know when performing a penetration test. Let’s explore each one:

Service-Level Agreement (SLA)

#

An SLA is a well-documented expectation or constraint related to one or more of the minimum and/or maximum performance measures (such as quality, timeline/timeframe, and cost) of the penetration testing service. You should become familiar with any SLAs that the organization that hired you has provided to its customers.

Confidentiality

#

You must discuss and agree on the handling of confidential data. For example, if you are able to find passwords or other sensitive data, do you need to disclose all those passwords or all that sensitive data? Who will have access to the sensitive data? What will be the proper way to communicate and handle such data? Similarly, you must protect sensitive data and delete all records, per your agreement with your client. Your customer could have specific data retention policies that you might also have to be aware of. Every time you finish a penetration testing engagement, you should delete any records from your systems. You do not want your next customer to find sensitive information from another client in any system or communication.

Statement of Work (SOW)

#

An SOW is a document that specifies the activities to be performed during a penetration testing engagement. It can be used to define some of the following elements:

• Project (penetration testing) timelines, including the report delivery schedule
• The scope of the work to be performed
• The location of the work (geographic location or network location)
• Special technical and nontechnical requirements
• Payment schedule
• Miscellaneous items that may not be part of the main negotiation but that need to be listed and tracked because they could pose problems during the overall engagement

The SOW can be a standalone document or can be part of a master service agreement (MSA).

Master Service Agreement (MSA)

#

MSAs, which are very popular today, are contracts that can be used to quickly negotiate the work to be performed. When a master agreement is in place, the same terms do not have to be renegotiated every time you perform work for a customer. MSAs are especially beneficial when you perform a penetration test and know that you will be rehired on a recurring basis to perform additional tests in other areas of the company or to verify that the security posture of the organization has been improved as a result of prior testing and remediation.

Non-Disclosure Agreement (NDA)

#

An NDA is a legal document and contract between you and an organization that has hired you as a penetration tester. An NDA specifies and defines confidential material, knowledge, and information that should not be disclosed and that should be kept confidential by both parties. NDAs can be classified as any of the following:

• Unilateral: With a unilateral NDA, only one party discloses certain information to the other party, and the information must be kept protected and not disclosed. For example, an organization that hires you should include in an NDA certain information that you should not disclose. Of course, all of your findings must be kept secret and should not be disclosed to any other organization or individual.
• Bilateral: A bilateral NDA is also referred to as a mutual, or two-way, NDA. In a bilateral NDA, both parties share sensitive information with each other, and this information should not be disclosed to any other entity.
• Multilateral: This type of NDA involves three or more parties, with at least one of the parties disclosing sensitive information that should not be disclosed to any entity outside the agreement. Multilateral NDAs are used in the event that an organization external to your customer (business partner, service provider, and so on) should also be engaged in the penetration testing engagement.

Conclusion

#

By incorporating these best practices, organizations and penetration testers can ensure regulatory compliance while maintaining a clear understanding of their legal obligations. As we consider Kenya’s Data Protection Act ,2019 ,having a globalperspective ensures we maintain and adopt the best practise when data is concerned.