Role-Based and User Group–Based Access

The two major categories of data access requirements or data access control covered in this section are role-based access control and user group–based access control.

Data Use Agreements and Release Approvals

Now, let’s look more closely at two data access requirements:

• Data use agreements

• Release approvals

A data use agreement (DUA) is brought into practice when moving protected data from one party to another. Specifically, a DUA is a contractual agreement between a data user or requester of access to information and the data provider or the organization or body offering the data. Protected data includes:

• Personally identifiable information (PII)

• Personal health information (PHI)

• Financial data

A DUA encompasses important topics such as right to use data (also called permitted use), liability arising from the use of data, privacy rights associated with the data, intellectual property rights, and obligations to use data properly. Some of the key aspects covered by a DUA are:

• Who has ownership of the data, and what are the terms of agreement?

• What type of data will be shared between the two parties (that is, the user and the provider)?

• What data will be shared outside of the two parties?

• What is the purpose for which the data will be used?

• Who is responsible for handling any violations of the agreement?

• What type of data security will be adopted?

Now that you understand DUAs, let’s focus on data release approvals.

Any private and confidential data (that is, protected data) that is to be released must have certain approvals aligned to it. These approvals are based on policies of an organization—and are often in line with local legislation. If an organization collects data about your health, for example, it should ask for your consent to release it to another organization for processing or analysis; in addition, it must follow the requirements of state and other bodies that govern how such data can be released to the organization’s wider network.

There are typically several requirements:

• The data must be managed as described in a data management plan.

• Any applications managing data and data flows must be well documented.

• Unique identifiers that identify an individual must be masked in transit/storage.

• The data repository must be well documented and adhere to applicable standards.

Data Encryption

Simply put, encryption is the process of converting plaintext or readily readable information into ciphertext—scrambled randomized characters that cannot be interpreted easily by someone who is not supposed to have access to the information. Keys are used to encrypt and decrypt data, and only the appropriate users (that is, the users who should have access to the data/information) can use them.

Further, encryption can be broadly classified as symmetric and asymmetric. With symmetric encryption, the same key is used for encryption (scrambling) and decryption (unscrambling). In contrast, when using asymmetric encryption, the encrypting key is different from the decrypting key. Symmetric key encryption is also known as shared key encryption, and asymmetric encryption is also known as public key cryptography. Figure 15.2 shows the processes of symmetric and asymmetric encryption.

Symmetric and asymmetric encryption can be implemented by leveraging algorithms such as:

• Blowfish: Blowfish is a symmetric cipher that has a variable key length from 32 to 448 bits. Blowfish is a block cipher, which means it divides data into fixed blocks (of 64 bits each) when encrypting data.

• Advanced Encryption Standard (AES): AES, which was established by the U.S. government as a standard for encryption, is a symmetric key algorithm that uses block cipher methods. AES is available in 128-bit, 192-bit, and 256-bit forms, with increasing numbers of rounds of encryption (so that 256-bit AES is more secure than 128-bit and 192-bit AES).

• RSA: RSA is a public key algorithm, and RSA-based asymmetric encryption is used extensively throughout the Internet. For example, security protocols such as SSH, S/MIME, and SSL/TLS leverage RSA.

• Elliptic Curve Cryptography (ECC): ECC is an asymmetric cipher that offers better security than RSA, with significantly shorter key lengths.

Why is it important to encrypt data? It is important to keep customer and organizational data private and safe from misuse. Data is more accessible than ever before, and the attack surface (that is, the touchpoints that a hacker can misuse to access data) is ever increasing, thanks to ubiquitous connectivity and access mechanisms. Just storing data in a database that is accessible via username and password is not enough to protect it. Someone who’s not supposed to get access to data may get it, but if the data is encrypted, the hacker will end up reading gibberish rather than what they came for. And without the right key, it’s very difficult to decrypt the data. Encryption protects valuable data and also helps organizations comply with data-related regulations.

Data encryption can be used for data that is being stored (that is, data at rest) and for data as it is being transmitted (that is, data in motion). Keys are only provided to authorized users.

Data encryption at rest encrypts data when it resides on a storage device and is not actively being used or transferred. Compared to data in motion, data at rest is much less susceptible to attacks and data exfiltration. However, data at rest is not immune to hacking attempts. Encrypting data at rest improves the security posture by reducing accidental or malicious exposure of data due to stolen devices, ransomware attacks, privilege escalation, credential theft, and so on.

Data Transmission

Data is considered in transit or in motion when it is moving between devices or from one database, data warehouse, or data lake to another database, data warehouse, or data lake. This movement might be over an insecure medium such as the Internet or over a more secure medium, such as a virtual private network (VPN) or Multiprotocol Label Switching (MPLS). Sometimes data is even moved from personal or corporate devices, such as from a laptop to a USB drive or from a DVD to a laptop.

It is easy to see why data is at such great risk during transfer: It has to pass through potentially insecure media and may be exposed to an unintended audience. Sometimes, security concerns might be with the vulnerabilities of the transfer method (for example, an Internet session being hijacked).

Encrypting data during transfer (sometimes also referred to as end-to-end encryption) safeguards data that is being moved from source to destination through one or more media. There are various ways to protect data during transmission, including:

• Encryption algorithms: A longer encryption key length offers stronger protection. Hence, when you’re selecting an encryption algorithm such as AES, consider going for AES-192 or AES-256.

• Mobile device management (MDM): It is pretty common today for organizations to allow employees to bring their own devices to work and to have corporate data such as emails or presentations on their personal devices. Data moving between corporate assets and these devices needs to be encrypted, and the security posture of such a device must be appropriate. This can be achieved by using a bring-your-own-device (BYOD) policy and MDM solutions.

• Secure wireless access: Almost everybody is on wireless networks at home or at an office, and wireless connectivity needs to be secure. Earlier wireless protocols such as Wired Equivalent Privacy (WEP) are considered to be very weak and are not recommended for use today. Wi-Fi Protected Access 2 (WPA2) and Wi-Fi Protected Access 3 (WPA3) are preferred protocols, and WPA2-AES and WPA3-AES offer maximum security for wireless clients. Further, rogue access points (APs) should not be allowed in a wireless network.

• Secure wired access: Servers are always hardwired, and sometimes you have to plug in a laptop to a corporate network. To secure the connectivity points (that is, switch ports) on these machines, you can deploy switch port security combined with Layer 2 and Layer 3 access control lists (ACLs), which allow only the relevant traffic to traverse.

• Data loss prevention (DLP): DLP can be used to ensure that any classified and protected data cannot be exfiltrated from the organization without proper approval. This helps ensure that any deliberate or unknown attempts to expose sensitive data are automatically thwarted.

Every organization should focus on encryption of both data at rest and data in motion as a baseline for good governance and ensuring that data integrity is maintained.

De-identifying Data/Data Masking

Many regulatory compliance requirements require data to be masked (or de-identified) before it can be transmitted or stored. Data de-identification/masking is different from encryption, where data is changed from its original form. With data masking, some fields or parts of fields may be masked to hide explicit information. An organization’s databases might contain personal and sensitive data, and one of the most effective ways to prevent exposure of the data is to mask it before it is used for analysis.

Data masking is important to satisfy multiple regulatory requirements, such as:

• Payment Card Industry Data Security Standard (PCI–DSS): Masking payment card data

• Health Insurance Portability and Accountability Act (HIPAA): Masking health data

• General Data Protection Regulation (GDPR): Masking personal data

• Family Educational Rights and Privacy Act (FERPA): Masking student data

• Sarbanes-Oxley Act (SOX): Masking U.S. public company and accounting firm data

Data masking can take two main forms: static data masking or dynamic data masking. Whereas static data masking masks data at rest, dynamic data masking is focused on data in motion (also known as on-the-fly data masking). Data de-identification is a form of dynamic data masking.

Figure 15.3 shows an example of static data masking.

It should be apparent from Figure 15.3 that all data that is deemed sensitive (that is, the account numbers) is masked. Any user trying to access this information will see only the masked data, regardless of the user’s role.

Static masking might not be useful when you have multiple users who should have different access to data based on their roles. For example, say that your organization wants to give full access to customer account information to sales and minimal access to IT. This can be achieved with dynamic data masking, illustrated in Figure 15.4.

As you can see in Figure 15.4, sales users have full access to customer data, whereas IT users only have access to customers’ names and part of the account information.

You can use services such as AWS Lake Formation to provide access to data for users in your organization based on their roles/functions. AWS Athena can also anonymize datasets by masking specified fields.

Acceptable Use Policies

An organization wants its users to abide by security policies and other policies, such as data protection policies, when using organizational IT assets. An acceptable use policy (AUP) spells out what end users can and cannot do with the organization’s assets and information. Organizations typically ask new organizational members and/or vendors as well as suppliers to sign an AUP before giving them permissions for the internal systems or information.

An AUP clearly defines the following:

• What end users can or cannot do with the corporate assets and information

• What happens when there is a breach of the AUP

• How to report any breach of the AUP

• Any compliance and other requirements associated with the AUP

The following are some of the aspects that can be expected to be covered in an AUP:

• Internet use

• Spam and email

• Clear desk

• Mobile device use

• Software use

• Monitoring

• Passwords

It is important for users to understand and accept the AUP before they are given access to organizational data and start leveraging it for analytics or reports. Their use of corporate data is based on their acceptance of the AUP.

Data Deletion

Many privacy regulations require that when an organization collects personally identifiable data, the organization must have a good data deletion policy/guideline in place. While on the business side, stakeholders may want to keep the data forever to drive decision making and prevent the need to collect the data again (which can be costly and time-consuming), on the security and privacy side, regulations limit data usage and retention.

Data deletion can be primarily of two types:

• User request based: Data deletion is usually mandatory when a user whose data was previously collected by the organization initiates a data deletion request. Such a request requires that certain types of data be deleted, such as user contact details or any transactional data. There may be some exceptions to data deletion requirements, including things like retaining data that is required for compliance and legal reasons.

• Regulation enforced: This type of data deletion, sometimes known as data purging, is commonly based on local or international privacy regulations. Data retention (covered in the next section) should be closely related to the organizational and regulatory requirements, and after the data retention cycle is over, data must be deleted/purged in accordance with compliance and/or regulatory requirements.

Cloud providers have formed user request–based deletion processes that are easy to understand and follow. For example, Google Cloud Platform (GCP) has clearly laid out a process for data deletion on Google Cloud (see https://cloud.google.com/docs/security/deletion).

The four stages of a data deletion request in GCP are as follows:

• Stage 1: Request for deletion

• Stage 2: Soft deletion of data

• Stage 3: Logical deletion of data from active systems

• Stage 4: Expiration of data from backup systems

You can review the stages of Google Cloud’s deletion pipeline at https://cloud.google.com/docs/security/deletion.

The data deletion process can be very easy or very complex, depending on the organizational data use requirements as well as global or local requirements about safe disposal of customer data.

Data Retention

As briefly mentioned in the previous section, data retention guidelines define how long user/consumer data can be retained as well as how the data should be stored (for example, whether it needs encryption, who can access it and how). In other words, a data retention policy defines how long data can be kept by an organization before it can be securely disposed of or purged.

To simplify the process of data retention, an organization may create a data retention policy that provides directions for storing, holding, and deleting data. A data retention policy should be managed and owned by defined stakeholders within an organization and should meet both organizational needs and regulatory requirements.

Some of the key elements of a data retention policy are as follows:

• The time period for keeping each type of data

• The regulations that apply to the information collected

• Details of data acquisition, such as from whom, where, and why the data was collected

• Details on how the organization will store, secure, back up, and purge the information

• Directions on what should be done in the event of data breaches or policy violations

In the United States, there are a number of data retention regulations. For example, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) protects individuals’ health data, and the Gramm-Leach-Bliley (GLB) Act places a duty on financial service providers to explain to their customers how their information is shared.

Record Link Restrictions

Not all data is created equal, and organizations often need to combine data from various sources to get a better picture. In such cases, linking multiple datasets can help alleviate data quality issues. In many cases, linking multiple records can lead to better data quality as well as a better sample size (for statistical analysis). Record linking can be performed by identifying a unique identifier across datasets to be linked.

From a governance point of view, it is important to note that records that might contain personally identifiable sensitive information should not be exposed to unauthorized personnel. Linkage from within the organization or from outside the organization (for example, with vendors or suppliers) should be controlled based on a need-to-access basis. Every record must have a security classification that determines who can access (or link to) the record. The most commonly used levels are public, private, and restricted, but an organization can set its own levels.

A more sophisticated way to ensure that record linkage works properly is to apply digital rights management (DRM) restrictions to the records. DRM restrictions can be attached to records and move wherever the records go or are linked. DRM solutions offer encryption of information and controls such as time-based deletion or automatic deletion of records, disabling of saving or printing, and inability to change records without the appropriate security level.

Data Constraints

It is important to protect data from unauthorized changes or deletions. You can use data constraints (that is, rules) to effectively enforce the type of data that can be inserted, updated, or deleted from a table or a column. Whereas table-level constraints apply to a whole table, column-level constraints apply to a specific column.

Why would you apply constraints instead of using access rights or data encryption? While the right level of access (based on the classification level) blocks unauthorized users and encryption keeps prying eyes off the data, neither of these solutions protects against human error or sabotage. Constraints prevent accidental and intentional change of data and offer a way to increase the accuracy and reliability of the data in a database.

The following constraints are typically used by database administrators:

• Primary key: Ensures that each record has unique values—and no null values.

• Foreign key: Enforces binding between two tables and verifies the existence of one table’s data in the other table.

• Uniqueness: Ensures that columns have unique values.

• Default value: Assigns a default value to a column when there is no value provided.

• Check: Ensures valid entries for a given column by restricting the range of values, types of values, and format of values for the fields.

Cardinality

In the context of data modeling, cardinality (or relationship cardinality) refers to how one table relates to another table. For example, 1:1 implies that one row in Table 1 relates to one row in Table 2. In addition, there are other relationships, such as 1:N (that is, one-to-many), N:1 (that is, many-to-one), and N:N (that is, many-to-many).

Using our earlier example, Figure 15.6 shows the cardinality between the seller, the product, and the customer.

Mapping relationships is great when it is done and leveraged by the intended audience; however, to properly implement governance around who can map what across databases, you should consider access-based and constraint-based controls. You want to ensure that only personnel with the proper level of access and ability to change constraints can amend data in a database and map it across other databases.

Personally Identifiable Information (PII)

It is important for an organization to choose a data classification methodology and use it to classify and categorize/prioritize software according to the kinds of data that the software handles. One of the ways to classify software based on the data it uses is to focus on personally identifiable information (PII).

PII is regulated data that could possibly identify a specific individual. It includes the following:

• First and last names

• Physical addresses

• Personal and corporate email addresses

• Credit card numbers

• Birthdates

• Passport numbers

• Social Security number (SSNs)

• Driver’s license and plate numbers

• Biometric data (such as fingerprints, voice prints)

• Medical records

PII can be classified as sensitive or non-sensitive. Sensitive PII is information that, upon disclosure to an unsanctioned person/entity, might result in maltreatment of the person whose data has been shared. On the other hand, the disclosure of non-sensitive PII is not likely to result in maltreatment of the person whose data has been shared.

In classifying PII data, at least the following data classifications would be required:

• Private: This classification includes data that a user or consumer does not wish to disclose. The disclosure of this data would result in a moderate level of risk to the individual. This data may include information such as home address and date of birth, and it would only be found in customer-specific databases, such as e-commerce records or survey records. This is the type of data that the organization would need to preserve and keep away from prying eyes (such as hackers). This classification requires security controls and access methods, including the ones discussed earlier—such as network security controls, access controls (for example, role-based access control), and masking—to ensure that only authorized individuals can access the data and that the data is not exchanged with another organization without prior approval of the user/consumer.

• Public: This classification refers to data that the user or consumer agrees can be used in the public domain or publicly. The disclosure of this data would result in minimal to no risk to the individual. Public data may include data such as a person’s name, email address, and designation in an organization. This is data that can usually be found in public records, on social media, in telephone and/or business directories, and in blogs. Because this data is available publicly and anyone can access it, an organization must apply appropriate security access controls to prevent the unauthorized alteration or destruction of this user/consumer data.

• Restricted: This classification includes data that is strictly limited to use within the organization that collected it; under no circumstances should it be disclosed to anyone except people who should have access to it. The disclosure of this data would result in a very high level of risk to the individual. This data includes highly sensitive information such as SSNs, credit card numbers, medical data, and license details. A leak of data classified as restricted would disclose information that could easily identify an individual and allow hackers or other attackers to harm the individual by hacking their accounts or identity or by harming them physically or emotionally. This data requires the highest level of security to ensure that it is not even accessible by employees of the organization unless they have the right or need to access it.

Personal Health Information (PHI)

Personal health information (PHI) is protected by the Health Insurance Portability and Accountability Act of 1996 (HIPAA). HIPAA helped establish baseline security controls and safeguards to administratively, technically, and physically uphold the CIA triad for health and medical data.

Electronic protected health information (ePHI) is any PHI that is created, stored, received, and transmitted electronically, using electronic media such as computer disk drives, memory cards, optical discs, or health care networks.

PHI is very similar to PII in that PHI is any individually identifiable health information, such as the following:

• Patient’s name

• Patient’s physical address

• Patient’s SSN

• Patient’s general health history

• Patient’s healthcare services

• Patient’s mental health history

• Patient’s medical record number

• Patient’s health insurance beneficiary number

• Patient’s license plate number

• Patient’s biometric identifiers (fingerprints, voice prints, and so on)

PHI is typically classified using the same three classifications as PII: public, private, and restricted.

Payment Card Industry (PCI)

Much as PII and PHI focus on personally identifiable individual and health information, PCI focuses on an individual’s payment card information, such as:

• Card numbers

• Card expiration dates

• Card verification value (CVV2) codes

• PINs

The Payment Card Industry Data Security Standard (PCI-DSS) applies to organizations that process, store, or transmit cardholder data, including:

• Merchants

• Card-issuing banks

• Payment processors

• Point-of-sale machine providers

At a minimum, the PCI-DSS security standard requires that an organization that processes, stores, or transmits cardholder data meet the following conditions:

• The organization secures and protects cardholder data.

• The organization maintains an information security policy.

• The organization builds and maintains a secure network.

• The organization maintains a vulnerability management program.

• The organization regularly monitors and tests networks for vulnerabilities.

• The organization implements strong access control measures.

PCI-DSS requires data classification to reduce the risks associated with unauthorized disclosure and access. PCI-DSS directs organizations to perform regular risk assessments and to review the security classification process. Cardholder data must be classified by type of data, the retention permissions, and the level of protection. The levels of classification are the same as those of PII and PHI:

• Public

• Private

• Restricted

Impact of Industry and Government Regulations

It is important to understand that data can be stored just about anywhere, and where it is stored sometimes dictates how it can be used. Data sovereignty governs how data can be accessed if it is stored within the country of origin vs. if it is stored in a different country; different laws and governance may apply to the data use.

If an organization operating outside the United States hosts its data in a data center such as an AWS or Azure data center in the United States, the U.S. government has access to that data. Many organizations and their stakeholders may not even be aware of the fact that their data is hosted in another country, and they may be at risk of losing all access to their data or having their data used by the local government without their permission.

For example, according to the U.S. Patriot Act, the U.S. government has access to any data held within its borders as well as all data of companies that operate within the United States.

As another example, the General Data Protection Regulation (GDPR) has had a huge influence on those doing business with EU members as well as on EU members in other jurisdictions. Basically, any organization that has a business or handles transactions in the EU with EU members needs to abide by the GDPR; in addition, any other organization worldwide needs to consider its dealings with a person of EU origin in accordance with the GDPR. The GDPR is perhaps the single most significant regulation affecting businesses in the EU and the rest of the world.

Regulations have a big impact on businesses. The challenge that businesses face is that they do not have to deal with just a couple of simple local or international regulatory requirements that do not change over time; rather, they have to deal with multiple ever-changing and complex local and international regulations in multiple jurisdictions. This complication can impact the velocity with which businesses innovate and grow.

On the flip side, once customers realize that they are in control of how their data will be managed, they are often willing to share more and more data, knowing that it will benefit them as organizations work to make new solutions and offerings available to suit their needs. For example, Apple recently started giving users a choice about how apps can track their activity across other apps on iOS (see Figure 15.7). This is exactly what many consumers want—control over the way their information is used and shared. Such options instill confidence in consumers and allow them to share more information as they see fit.

While this isn’t a direct regulation that Apple has enforced on all Apple Store apps, it is a way to show that the company cares about customers’ privacy.

Escalating to the Appropriate Authority

When a data breach occurs, it is crucial to be able to respond to it in a timely manner. An organization might have a data breach management committee, and the members of the committee should respond to a breach appropriately and make any regulatory bodies aware if the breach leads to the loss of sensitive, confidential, or restricted data. The following high-level steps should be taken in responding to a data breach:

1. Try to contain the breach: Sever the hacker’s connections or take critical systems off the affected network segments.

2. Evaluate the risks: Ensure that the risk management plan helps identify the type of data that was lost.

3. Start recovery: Ensure that any critical systems are back online and are secured.

4. Escalate to senior management and relevant bodies: Ensure that all local bodies and organizational executives who should be informed are aware of the situation.

5. Notify affected individuals: Reach out to the individuals who were or could be affected by the data breach.

6. Investigate the cause of the breach: Try to determine the cause of the breach and how similar attempts can be thwarted in future.

It is crucial to contain a breach and to notify the appropriate local bodies so they can help with the remediation as well as manage the next steps.

In the United States, all 50 states have passed breach notification laws that require organizations to notify state residents of security breaches. These laws apply to sensitive categories of information, such as SSNs, credit card information, financial account numbers, health or medical information, birthdates, online account credentials, and digital signatures and/or biometrics. Moreover, U.S. federal laws require notification in the event of a breach of healthcare information, telecom usage information from service providers, information from financial institutions, and government agency information. Almost every aspect of sensitive, restricted, confidential, or higher tiers of classification requires some kind of reporting.

To contain data breaches, an organization may have a data breach policy that is managed by a data breach management committee. A data breach policy should include details about:

• Responding to a breach of data, including managing a data breach

• Notification of individuals whose privacy may be affected by a breach

• Documentation of a breach and the appropriate reporting (both internal and external)

• Organizational communications during and after a breach