However, this is explicitly not about user accounts and what some may call “digital identities”. It’s also not about non-human identities (NHIs), workload, service, machine-to-machine, or customer accounts. 

There are a lot of great articles already written on each and every one of these identity types by thought leaders, so I’d like to address the neglected others.

So, if this article is about identities, but none of the above, then what’s this article about? This is about other constructs that are fundamental to all Identity and Access Management programs, and to their related tools and applications. I’m referring to the identities of constructs like groups, applications, policies, networks, etc.

Identity Constitution

Allow me to simplify the constitution of ‘Identity’ into having three parts: 

1. An identifier (as unique as possible)
2. Attributes, which provide further differentiation, context, etc.
3. Relationships (e.g., “belongs to”), which can be documented as part of #2

“My dog’s name is Lola” ← These five words already encompass the three parts above:

1. Her identifier: Lola
2. Attributes: type: Dog
3. Relationships: owner: Me (although, if Lola could talk, she’d tell you her human is my wife)

An example of a non-living object is “my lucky t-shirt”. I’ve had this t-shirt for years, and it’s green, and it has a print of mountains with “Colo ‘rad’ o” written above (I’m a dad, I love it). At home, I may say, “have you seen my lucky t-shirt?”, and in the context of my family, chances are they’d know which one I’m talking about. If my daughter is not sure which t-shirt I’m talking about, she may ask, “what color is it?” (It’s green, an attribute). Life gives us an extensible schema to define any number of attributes to identify objects.

In the examples above, I shared the ‘Identities’ of two objects. The point is to ‘identify’ them.

If we turn to IAM-related objects, we can look at groups as in immediate need of proper identification. A group’s system identifier may be “xyz123”, attributes may include Group Name = “App X Users” (this may be considered the identifier, to the human eyes at least), and Group Description = “Accounts with access to App X”. Is this sufficient? Perhaps initially you’ll think “absolutely”. I’d argue that there’s a rich group identity hidden behind the ID, Name, and Description for this group. 

The IAM systems I’m most familiar with allow me to define a rich, extensible schema for accounts with many different attributes and even different attribute-types (string, Boolean, array, etc). This is excellent and much needed. In the last few years, the ‘group schema’ became available, so I may now define a Boolean value ‘For SSO’, ‘For SCIM Provisioning’, or ‘For Policy’. In addition, I want to define ‘Pushed to App’ as a Boolean value, and if TRUE, then ‘App’ (string type, as I can’t define an App object relationship).

But, there’s no extensible schema for ‘Apps’, or for ‘Group Rules’, or ‘Policies’, or ‘Networks’, etc. Lots of opportunities here to elevate the schemas of other objects to a whole new level. 

The CMDB is an Identity Management system

It follows that the system of record for constructs such as applications, systems, and perhaps groups is actually an IAM system, but for constructs other than accounts.

A proper CMDB will contain the creation date for any of its configuration items (CIs), its reason for being, its location, and, importantly, its relationships to other CIs.

A Source of Truth

One way to make your IAM system compliant and elevate its security is to delegate account creation to the correct source of truth. HR-driven provisioning is one example of this. If the IAM system delegates employee account creation to a correlated HR record, and the permissions to create accounts are removed from humans, a bad actor would have to shift their tactics to the HR system in order to create an account, which would likely require creating a role requisition, an applicant account, and then a hire/onboarding process.

Similarly, if the base attributes for a group, application, or other IAM construct are established and properly governed by the right source of truth, then the entire identity fabric will be more secure and compliant, but it’ll be like a self-maintaining organism, keeping the parts that are needed and auto-shedding those that have come to the end of their useful existence. 

Naming Conventions Don’t Work

You’ve likely implemented or have seen many naming conventions implemented to address this very topic. In my experience, a naming convention typically encodes attributes into the name (perhaps into a `Description`) with the intent to give more context to the object. This may work in some situations and it may help humans visually inspect the object. The problem begins when these existing encoded dimensions change or no longer capture the entirety of the object’s schema. When faced with this challenge, proper hygiene means renaming all existing objects, or, in the more common scenario, breaking the naming convention altogether. The end result is heterogeneous names and paralysis due to confusion and the need to research.

Suggested Actions

If you have access to an extensible schema for your objects, use it. Give those objects a rich identity that empowers a complete lifecycle of the object, from creation to decommissioning.

In the case of our Lola, she has her tag on her collar with her name and our cell phone numbers. However, she also has a microchip that extends the schema of her attributes to include our details, her vaccinations, etc. in case she gets lost and loses her collar.

If you’re building or managing IAM software, expand the universe to enable rich schemas in the system. Some of us may want to have a “lucky” group/policy/agent, and we certainly want better ways to identify and protect our Lola’s.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

About the author

Pablo Valarezo is an Identity practitioner building and modernizing secure IAM programs over the last decade. His primary focus has been in the workforce side of IAM. He came to Information Security via system administration, project management, and audit and compliance.

The post The Identity of Everything… Else appeared first on IDPro.

This is the last article of a series of four on the basics of the General Data Protection Regulation (GDPR). In the first article, we covered context, motivations, and goals. In the second article, we reviewed terminology and basic definitions. In the third article, we discussed examples and applications of some of the main building blocks of GDPR. In this fourth article, we review some of the most critical issues in the GDPR while identifying, classifying, and analyzing each one in practical terms.

Without any concrete instance of an application subject to GDPR compliance, one might look into the GDPR text from a dangerously relaxed perspective which can lead (and it has been leading) to GDPR violations, overwhelming fines, and further administrative penalties. On the other hand, generally speaking, it is not always clear how to ensure GDPR compliance. Resorting to the GDPR text without a strategy might feel like drinking from a fire hose. The whole point of this series of four articles on GDPR was to propose a gentle introduction to the subject matter in a gradual, structured way.

The primary motivation behind this fourth and last article is to propose a way to identify key regulatory components that can be classified into major groups so we can discuss their importance and practical implications. 

We organized the following discussion in four major groups: Must Know, Must Do, Better Have, and Better Do. It goes without saying that this is a non-exclusive and non-exhaustive discussion. Instead, for each of these major groups, we will select one or a few examples that configure a good start on the road to GDPR compliance. The “analysis” piece of this article will be presented as an informal discussion to keep this article within an acceptable length.

Must Know

If there are components that anyone interested in GDPR must know, these are probably the applicability and non-applicability of the Regulation and associated fines. The GDPR text can sometimes be very specific and practical, while some other portions leave too much room for interpretation. In any case, establishing a knowledge foundation is the best one can do towards GDPR compliance.

Applicability and Non-Applicability of the GDPR

The General Data Protection Regulation (GDPR) establishes rules for protecting natural persons concerning the processing of personal data (Article 1). The GDPR “applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system” (Article 2). The Regulation applies to any data processing related to members of the European Union (EU) regardless of the processors’ location. (Article 3)

Natural person and data subject are synonymous. Personal data is a term for data that reveals information that identifies or has the potential to identify a natural person. Processing is the term used to describe any operation executed on personal data. A processor is a term to describe a natural or legal person who processes data (Article 4).

The GDPR does not apply to “the processing of personal data which concerns legal persons and in particular, undertakings established as legal persons, including the name and the form of the legal person and the contact details of the legal person” (Recital 14). Legal entities many times operate as a processor. Although the GDPR does not apply to data that identifies legal entities, legal entities often possess data that identifies natural persons (their customers). Therefore, GDPR protects these customers’ right to privacy (Article 28).

Penalties

Perhaps the most important exercise an organization intending to process data that can be seen as personally identifiable information (PII) can do is to identify what from the GDPR applies and does not apply in the context of the application that the organization is responsible for. It is not rare to see organizations downplaying the need to comply with privacy regulations such as the GDPR in an attempt to overlook its severity. However, in 2021, the GDPR issued fines up to $823.9 million for violations. 

Violations can seem subtle for some organizations already in possession of personal data. In 2020 the GDPR issued a fine of $29.3 million to a company that failed to obtain consent or to inform customers about using their personal data for telemarketing purposes.

The first step towards compliance is, obviously, to know the requirements and their applicability. In some portions of its text, the GDPR advises that in case of doubt, the requirement must be fulfilled regardless, such as in the case of performing a privacy impact assessment.

Furthermore, all the general conditions for imposing fines, with different levels of severity, can be found in Article 83 of the GDPR. 

The GDPR establishes fines and further remedies or corrective powers when a violation occurs. Fines must be “effective, proportionate and dissuasive for each individual case. For the decision of whether and what level of penalty can be assessed, the authorities have a statutory catalogue of criteria which it must consider for their decision”. Severe violations (Article 83) are subject to fines of up to 20 million euros or up to 4% of an organization’s global turnover of the preceding year, whichever is higher (GDPR Fines and Penalties).

Must Do

Not all procedures and specifications in the GDPR are mandatory, and most of what is mandatory is subject to exceptions under proper conditions. However, if there is one issue above all others that can never be neglected, that could easily be the requirement for consent. We discussed consent in the previous articles of this series, and we return to this subject to place it in the Must Do group from a practical perspective.

Consent 

As we discussed in previous articles of this series, if an organization aims to process personal data, a mechanism for obtaining the consent of data subjects must be in place. According to Council Directive 93/13/EEC, consent must be requested via a pre-formulated interface presented in an intelligible and easily accessible form, using objective and easy-to-understand language, avoiding any terms that might be considered unfair. Before providing consent, the data subject should have no doubt of the controller’s identity and the purpose of processing personal data that is being requested.

The Regulation summarily prohibits the processing of personal data unless expressly allowed by law or by the data subject. Besides consent, other mechanisms also apply for allowing the processing of personal data, such as contract, legal obligations, vital interest of the data subject, public interest, and legitimate interest according to Article 6(1). Processing personal data in the clear without consent or the previously mentioned mechanisms is a violation. (Key Issues: Consent)

Recall that consent must be “freely given, specific, informed, and unambiguous.” If processing personal data has been enabled by consent, whoever is processing that data must be able to prove that the data subject has indeed consented to the processing of their data. The data subject has the right to withdraw their consent at any time, and this process must be as easy as it was to give the consent. Withdrawing consent does not affect the lawfulness of the processing of data based on consent before its withdrawal. Conditions for Consent, Article 7, is part of the main principles of the GDPR.

At any indication that consent was obtained under pressure, penalty, and/or by some form of imposition, consent will not be regarded as freely given since, in this case, the data subject is unable to refuse or withdraw consent without detriment.

The GDPR prohibits the processing of personal data that reveals “racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data to uniquely identify a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation.” Article 9 establishes several exceptions to this prohibition, including law enforcement activities, support of court procedures, public interest, and legal inability of a data subject to give consent.

The processing of data (by third parties) that leads to identifying data subjects is a violation of the GDPR. (Key Issues: Personal Data)

Processing of personal data is allowed when the processing no longer permits the identification of data subjects, provided that appropriate safeguards exist, such as pseudonymization (Recital 156).

Consent for personal data collection and processing for a particular purpose is not everything and certainly not the end of an organization’s concerns with respect to GDPR compliance. Still, it is undoubtedly one of the most important first steps toward the lawful processing of personal data.

Better Have

The term “better” here does not imply any relaxation with respect to obligations imposed by the GDPR. As mentioned earlier, some requirements are followed by conditions and exceptions which might release an organization from associated obligations. The term “better” here implies that even if it is not objectively mandatory, some requirements are so important that it is better for an organization to address them than otherwise. That is, the benefits of implementing some measures outweigh any associated inconvenience.

Data Protection Officer

The GDPR establishes the concept and conditions for the obligation of organizations to have a Data Protection Officer (DPO). The legal obligation to appoint a DPO does not depend on the size of the organization “but on the core processing activities, which are defined as those essential to achieving the company’s goals. If these core activities consist of processing sensitive personal data on a large scale or a form of data processing which is particularly far-reaching for the rights of the data subjects, the company has to appoint a DPO.” The GDPR also establishes that “willful or negligent failure to appoint a Data Protection Officer despite a legal obligation is an infringement subject to fines” (Key Issues: Data Protection Officer).

Organizations need to take the need and role of a DPO seriously. The DPO must be impartial and empowered to assist the organization in implementing all necessary protective measures to meet GDPR requirements. The DPO cannot perform functions that place them in a position of conflict of interest.

Electing a DPO is one of those measures that an organization processing personal data might want to have in place regardless of a clear conviction of its legal obligation, providing immediate benefits versus risks and penalties associated with failing to do so.

Additional information about the DPO, including the associated qualification they might have and how to hire one, is available.

Better Do

Once again, “better” here does not intend to relax any obligations from the Regulation. Instead, we use it to identify and put together mechanisms, procedures, and requirements which are better to address even if an organization falls into some condition in which it is not obligated to comply.

Privacy Impact Assessment

An organization that intends to process data must first conduct a privacy impact assessment (PIA) or data protection impact assessment (DPIA) and document it. If certain measures are in place, a PIA or DPIA might not be absolutely necessary. A PIA or DPIA is mandatory if risks from data processing are high. In case of doubt or difficulty in determining risk, a DPIA should be conducted. (Key Issues: Privacy Impact Assessment)

Records of Processing Activities

When personal data is processed, the GDPR obligates written documentation and an overview of the procedures by which personal data is processed. (Article 30) This documentation must be made entirely available to authorities upon request. (Key Issues: Records of Processing Activities) Not maintaining records of processing activities is a violation of the GDPR (Article 83(4)(a)).

Procedural Rights

A data subject has the right to access personal data being processed. Omitted or incomplete disclosure of access to personal data being processed upon request is subject to fines. (Key Issues: Right to Access) Any right provisioned by the GDPR, such as the Right to be Forgotten and the Right to be Informed, must be observed when applicable. 

Safeguards

The GDPR establishes that security measures must be considered and implemented according to risk assessment. These measures include (but are not limited to) pseudonymization, encryption, mechanisms for ensuring confidentiality, integrity, availability, and resilience, regular testing, ongoing evaluation of the effectiveness of present measures, and continuous improvement of the security of processing (Article 32).

Data Minimization

Data minimization is the term used to describe “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed” (Article 5). It is about only collecting and processing data that is absolutely required for the purposes stated when consent was requested.

Data minimization can prevent organizations from accidentally violating GDPR requirements for processing personal data, such as purpose limitation, where data is only collected for the legitimate purposes stated when requesting consent and not further processed in a way that violates its limits. Data minimization can also reduce risks and liabilities when processing personal data, such as in the case of data leakage.

Processing personal data might be allowed for particular purposes such as archiving, scientific or historical research, or statistical purposes as long as appropriate safeguards are in place. These safeguards aim to ensure that required measures are in place, particularly the principle of data minimization (Recital 156).

Data minimization is part of general data protection principles recognized by the GDPR, such as purpose limitation, limited storage periods, data quality, data protection by design and by default, the legal basis for processing, processing of special categories of personal data, measures to ensure data security, among others (Article 47).

Anonymization

The GDPR does not apply “to anonymous information, namely, information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.” Furthermore, the GDPR “does not, therefore, concern the processing of such anonymous information, including for statistical or research purposes” (Recital 26).

Although allowed by the GDPR, it is well known that techniques such as anonymization are faulty (Broken Promises of Privacy: Responding To The Surprising Failure of Anonymization). At least since the late 2000s, schemes for de-anonymizing data have been proposed (Robust De-Anonymization of Large Sparse Datasets).

Pseudo-anonymization

Pseudonymization “means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organizational measures to ensure that the personal data are not attributed to an identified or identifiable natural person” (Article 4).

The GDPR establishes that techniques such as pseudonymization can reduce risks to the data subjects and help controllers and processors meet their data-protection obligations. The explicit introduction of pseudonymization is not intended to exclude any other measures for data protection (Recital 28).

The GDPR acknowledges that techniques such as pseudonymization may be reversed by unauthorized parties, which constitutes a violation (Recital 85).

Encryption

Organizations can reduce the probability of a data breach as well as the risks of fines by resorting to the encryption of personal data. Processing data is naturally associated with a certain degree of risk. The GDPR recognizes encrypted data as unreadable by non-key owners, which therefore minimizes the risks in case of incidents during data processing. Furthermore, the GDPR recognizes encryption as the best way to protect data in transit and at rest (Key Issues: Encryption).

Authentication

User authentication is part of the concept of Privacy by Design discussed in the Regulation (Key Issues: Privacy by Design). If not done properly, instead of a safeguard, authentication can be an opening for a GDPR violation. One example would be to collect from a natural person more information than necessary for implementing an authentication mechanism and, from there, make inferences about the individual that exceeds the scope of authentication. The GDPR clearly states that personal data is, by nature, sensitive data (Recital 51). 

Requesting additional data for identification purposes is allowed if a controller can’t identify a natural person but is not mandatory. The controller should not refuse to take additional information from the data subject (Recital 57).

Where To Go From Here

The IDPro Body of Knowledge offers an introduction to the GDPR and a discussion on the impact of GDPR on identity and access management. The full GDPR text is available online in a friendly format. Some templates are also available such as the Data Processing Agreement, instructions on how to write a GDPR-compliant privacy note, and the Right to Erase Request Form. The European Data Protection Board has a GDPR-centric news feed which can be useful for keeping up with the latest developments about GDPR.

About the Author

David William Silva is a Senior Research Scientist at Symetrix Corporation and Algemetric and is responsible for the research and development of innovative products related to security, privacy, and efficient computation powered by applied mathematics. David started his career as a Software Engineer focused on web services and agile software development, which led him to be involved with several projects from startups to government and large corporations. After 17 years of conducting R&D in Brazil, David moved to the US to engage in scientific research applied to a global industry of security and privacy, which has been his focus for the past seven years. 

The post GDPR Part 4: Identification, Classification, and Analysis appeared first on IDPro.

These packages include one Identiverse event ticket, donated by Identiverse, and up to $1,000 for expense reimbursement, fully funded by generous donations from IDPro members.

“We are excited to be able to offer these Diversity & Inclusion Packages to the identity community. I have been a firsthand witness to the impact these values are having on this industry and am very proud of our organization for being able to support this effort.” — Heather Vescent, Executive Director and President of IDPro.

To be considered, please submit a personal statement of no more than 300 words to director@idpro.org by 11:59 PM PDT on June 7, 2022. Your personal statement should answer the following questions:

1. Can you please share a little bit about your background?
2. How did your interest in identity come about?
3. What do you hope to learn at Identiverse 2022?
4. Why are diversity and inclusion important to you?
5. Are you willing to write a brief blog post or be interviewed about what you learn at Identiverse 2022? 

Please include any social media links in your personal statement. 

Our vision at IDPro drives us toward enabling a diverse, supportive, and inclusive identity community and we are grateful for our dedicated members who are helping us achieve this important goal. We look forward to reviewing your submissions and we hope to see you at Identiverse 2022!

The post Announcing IDPro®’s Diversity & Inclusion Packages for Identiverse® 2022! appeared first on IDPro.