Category Archives: Compliance

What is classified as “Personal Data” in the General Data Protection Regulation (GDPR)?

The GDPR defines personal data (aka PII) as “data from which a living individual can be identified or identifiable (by anyone), whether directly or indirectly, by all means reasonably likely to be used.”

This could be directly (e.g. a person’s name) or indirectly (e.g. the owner of that business). The definition of personal data applies to any piece of information which can used to identify an individual, based on ‘all means reasonably likely to be used’.

For example, a user ID number is classed as personal data, because it can be matched to the name of a user on a database. The term ‘personal data’ still applies to data even if it requires the use of information elsewhere to identify an individual.

Personal data includes:

  • Identifiable information such as numbers
  • Factors specific to a person’s physical, physiological, mental, economic, cultural or social identity

However, it goes on to clearly state examples of this personal data, and specifically adds new identifying types of data to its definition. This includes:

  • Names
  • Location Data – Data that has any kind of geographic position attached to it. This is classified as personal because it could be used to identify where an individual lives, works, and sleeps, or to find out social, religious, or cultural identities.
  • Online identifiers – Digital information such as IP addresses, cookie strings or mobile device IDs. For example, as an IP address can be used to find out where an individual is located, it is clearly personal data.

As a subcategory of personal data, sensitive data refers to a more specific type of personal data that should be treated with extra protection. The current definition of this includes information such as:

  • Racial or ethnic origin
  • Political opinions
  • Religious or philosophical beliefs
  • Trade-union membership
  • Health or sex life

Under the GDPR, sensitive data is given more enhanced protection, with explicit consent required for its processing. Two new information types are added to this classification too: genetic data and biometric data.

Genetic data specifically refers to gene sequences, which are used for medical and research purposes. Biometric data includes fingerprints, retinal and facial recognition.

If you can identify an individual from any data held, then the data is “Personal Information” and it therefore falls within the scope of the GDPR.

Information Security Policies : A Cheat Sheet

Information security policies are a necessary evil.

The trouble is that very few organizations take the time and trouble to create decent policies; instead they are happy to download examples and cut and paste as they see fit. The resulting mess is often no good to anyone, and can often leave the business open to unforeseen issues.

Let’s look at a common scenario:

Your organization has been informed that you have to validate your compliance with the Payment Card Industry Data Security Standard (PCI-DSS). One of the daunting tasks ahead of you is having a policy in place that covers how your organization addresses all twelve requirements of the standard.

Do you have one in place?


You’re in luck! Consider this your quick information security policy cheat sheet. In my opinion, the following are the bare minimum policy components required to start building an effective information security policy, which will meet the requirements of many frameworks (not just PCI-DSS).

This section simply describes the reason why the policy exists (the “why”).

Scope and Applicability
This section states what assets, infrastructure, and personnel are covered by the policy (the “where”).

This section contains the overall body of the policy (the “what”).

Roles and Responsibilities
This sections contains information in regards to what roles (ie. IT Security Department, Helpdesk, etc.) are involved and what their responsibilities are in relation to the policy (the “who”).

Maintenance and Review
This section describes the frequency at which the policy is reviewed (preferably annually and/or after any significant changes have been made that will impact the policy).

References and Supporting Documentation
This section lists any related policies and/or procedures.

Terms & Definitions
This section lists any relevant terms and definitions contained in the policy.

A policy document should be a simple statement of the businesses position on the chosen topic, not to be confused with the procedural documentation which deals with how the policy is to be enacted. Procedures are sometimes necessarily much longer documents if they are describing processes which must be followed. System-specific security policies and corresponding procedures tend to fall into this category.

Ideally, the policy should be brief and to the point about the user’s responsibilities towards the information they collect, use, access or otherwise process, and to point them to the other relevant policies and procedures for the areas in which they operate.

By following these ideas, you should be able to create an effective information security policy, but more importantly have employees that are effectively looking after your organization’s assets. Information security policies provide vital support to security professionals as they strive to reduce the risk profile of a business and fend off both internal and external threats.

In short, what makes a good policy?

  1. It is relevant to your audience
  2. It is aligned to the needs of the business
  3. It is applicable to the compliance and/or regulatory frameworks in which you operate
  4. It is as short as possible.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. For more on these topics, visit Dell’s thought leadership site sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

PenTest vs. VA: One Of These Things Is Not Like The Other

As a QSA, I’m often required to review the results of a vulnerability assessment and a penetration test as part of an overall security assessment. When I ask my clients for each report, I often get this response:

“Aren’t they the same?”

They aren’t. While somewhat similar in concept, they produce distinctly different results.

Penetration tests (commonly known as PenTests) are used to identify methods of exploiting vulnerabilities with the intention of finding security weaknesses in a system, potentially gaining access to it, its functionality and data. It’s a mainly manual process that can include vulnerability scanning and other automated tools. At the end of the engagement, an extensive report is generated. Its contains a description of each vulnerability verified and/or potential issue discovered. More specific risks that vulnerability may pose, including specific methods how and to what extent it may be exploited. Examples of vulnerabilities include but are not limited to SQL injection, privilege escalation, cross-site scripting, or deprecated protocols. PenTest engagements may last days or weeks depending on the scope of the tests and size of the environment to be tested. Tests may grow in time and complexity if efforts uncover additional exploits.

Vulnerability scans (commonly known as VAs) identify, rank, and report vulnerabilities that, if exploited, may result in an intentional or unintentional compromise of a system and/or network. Typically a variety of automated tools are used in combination with manual verification of identified issues. These tools list the potential risks posed by known vulnerabilities, ranked in accordance with NVD-CVSS base scores that are associated with each vulnerability. Scans usually take a short amount of time, which can range from several seconds to several minutes per scanned host.

A vulnerability assessment should be performed regularly to identify and remediate known vulnerabilities on an ongoing basis. A penetration test should be performed at least annually and after significant changes in the information systems environment to identify exploitable vulnerabilities in the environment that may give a hacker unauthorized access to the system.

While vulnerability assessments and penetration tests are a requirement for PCI DSS compliance, it would be beneficial for companies to include the procedures in their overall security program even if they aren’t required to be PCI compliant. When used in conjunction with each other, they are an excellent indicator of a company’s security posture.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. For more on these topics, visit Dell’s thought leadership site PowerMore. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.





Just When You Thought You Had A Handle On PCI-DSS 3.0

As I mentioned in a previous post, PCI-DSS 3.0 (Payment Card Industry Data Security Standard) came into effect on January 1.

PCI-DSS 3.1 is on now its way, thanks to vulnerabilities like P.O.O.D.L.E.Shellshock, and Heartbleed.

The PCI SSC (Payment Card Industry Security Standards Council) continuously monitors threats and vulnerabilities in order to keep the security standard up to date.

The National Institute of Standards and Technology has identified SSL (Secure Sockets Layer) – a protocol meant to establish encrypted communication between a server and a client – as no longer acceptable for data protection.

Due to the inherent weaknesses of this security protocol, there are currently no versions of SSL with the ability to provide strong cryptography. This is why an updated version of the PCI Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA DSS) is necessary.

According to NIST, “The proper management of cryptographic keys is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration.”

The problem lies in the way the information is encrypted when being transmitted from a client to a server.

The solution is the dropping of SSL in favor of the TLS 1.2 protocol. SSL and the Transport Layer Security (TLS) are both mechanisms to protect sensitive data during electronic dissemination across networks. TLS 1.3 is currently being developed; the goal is to add extra measures to avoid exploitation and mitigate encryption-related issues.

To ensure the continuity across the payment card industry, the PCI Council expects that the PCI DSS 3.1, once published, will be effective immediately. That being said, the new requirements will need some time to be implemented and the PCI SSC will give some time to allow organizations to look into the new requirement and implement the changes.

Considering that there is no known way to address the weaknesses discovered in the SSL protocol, it is strongly recommended that all organizations that handle cardholder data look into the possibility of switching to a strong cryptographic protocol, such as TLS, as soon as possible. There are a number of ways to do this for WindowsLinux, and FreeBSD servers and clients.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. To learn more about tech news and analysis visit Tech Page One. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

PCI-DSS 3.0: Translating new credit card data security rules

Merchants that process, store, or transmit credit card data are now required to be compliant with version 3.0 of the PCI Data Security Standard (PCI-DSS).

There are a small number of requirements that are considered best practice until July 1, 2015. After which, they become mandatory.

Now you could search through the rather substantial standard to find the requirements in question, but I’ve saved you the trouble.

The PCI-DSS says:

“8.5.1 Additional requirement for service providers: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer.

To prevent the compromise of multiple customers through the use of a single set of credentials, vendors with remote access accounts to customer environments should use a different authentication credential for each customer.”

In short: Merchants need to hold their service providers accountable!

The PCI-DSS says:

“9.9 Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution.

Criminals attempt to steal cardholder data by stealing and/or manipulating card-reading devices and terminals. For example, they will try to steal devices so they can learn how to break into them, and they often try to replace legitimate devices with fraudulent devices that send them payment card information every time a card is entered. Criminals will also try to add ‘skimming’ components to the outside of devices, which are designed to capture payment card details before they even enter the device.”

In short: Make sure your physical POS hardware is secure!

The PCI-DSS says:

“11.3 Implement a methodology for penetration testing that includes the following:

  • Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)
  • Includes coverage for the entire CDE perimeter and critical systems
  • Includes testing from both inside and outside the network
  • Includes testing to validate any segmentation and scope-reduction controls
  • Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
  • Defines network-layer penetration tests to include components that support network functions as well as operating systems
  • Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
  • Specifies retention of penetration testing results and remediation activities results

The intent of a penetration test is to simulate a real-world attack situation with a goal of identifying how far an attacker would be able to penetrate into an environment. This allows an entity to gain a better understanding of their potential exposure and develop a strategy to defend against attacks.”

In short: Test and verify the effectiveness of your network segmentation!

The PCI-DSS says:

“12.9 Additional requirement for service providers: Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

This requirement applies when the entity being assessed is a service provider. It is intended to promote a consistent level of understanding between service providers and their customers about their applicable PCI DSS responsibilities. The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. The method by which the service provider provides written acknowledgment should be agreed between the provider and their customers.”

In short: Update your contracts to include this acknowledgement!

If you need to implement any or all of these requirements, do it now. Do you really want to wait until June 30, 2015?

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. To learn more about tech news and analysis visit Tech Page One. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

Compliance: Hard core Dell users get it!

I arrived at Dell World in Austin Texas on November 4. For the record, I was not a Dell customer attending a Dell customer event—an outsider of sorts, not to say that I didn’t feel welcome. The famous Texas hospitality was more than evident!

Luckily I was able to select conference sessions ahead of time, as the selection was massive. Naturally, I gravitated towards any sessions that revolved around information security.

I attended a session which discussed compliance from a user’s perspective… how to effectively achieve it on your own, or as I like to call it “How to make the auditor happy.”

Data breaches are rampant… almost commonplace in this day and age. A week rarely goes by without at least one large corporation in the news for losing personally identifiable information due to inadequate security controls. Information security awareness is higher than it’s ever been, but understanding complex compliance requirements is an intimidating endeavour to say the least. Many users are starting to self-assess (even if not officially required to), but eventually get bogged down by the technical details and jargon. Hiring a security auditor is always an option, but many lack the financial resources to do so. Being able to attend sessions like these at Dell World is a great benefit to both its users and partners.

Here are some of the key takeaways from the discussion:

1. How to manage by automation

  • Administer and revoke access rights and permissions
  • Implement best-practice compliance reporting
  • Protect, retain and retrieve data for on-the-fly investigations
  • Enforce compliance with company policies across desktops, laptops, etc.

2. How to remediate by changing the way you operate

  • Implement preventative controls
  • Establish policy over accounts, privileges and resources
  • Establish perimeter boundaries through application control and visibility

 3. How to think like an auditor

  • Track security and performance indicators
  • Audit and report on user activity
  • Perform checks for segregation of duties
  • Enable real-time alerts
  • Establish Security and Compliance awareness training
  • Analyze access rights and permissions to critical data
  • Determine configuration settings and set baselines

There were numerous opportunities for me to reveal myself as a PCI Qualified Security Assessor during the session, but I decided to stay quiet in order to hear unbiased opinions from the attendees.

I wasn’t disappointed. The questions from the audience were thoughtful and challenging. They know too well that the real world often gets in the way when it comes to implementing adequate security controls, but at the same time they are taking compliance seriously.

It warms this auditor’s heart. Well done Dell.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. To learn more about tech news and analysis visit Tech Page One. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.