When a cloud customer uploads PII to a cloud provider who becomes ultimately responsible for the security of that PII?

"We are moving to the Cloud..." This is the new moda and we are in a new era. On-Premise Infrastructures are disappearing or are in sharp reduction due to the several advantages the Cloud provides:

• Elasticity: allocating resources in the cloud as needed is almost immediate. Organizations pay only for what they consume (PAYG = Pay as you Go)
• Simplicity: most of the resources are managed by a Web Interface so Cloud Customers do not have to care on how to configure the underlying layers.
• Scalability: if the Organization needs more resources for a short period of time, new computing resources can be assigned wihout any significant capital investment

So, it seems that Cloud can resolve most of the problems that Managers have to face on every day. Is this true? If everything have been analysed correctly, I will continue to say "no". Cloud cannot resolve all the security an Organization has with just a snap of the fingers! Data is moved to another entity, so other layers, risks and threats are introduced.

On the market there are several XaaS cloud models but the 3 fundamentals are:

1. Infrastructure as a Service (IaaS): this is the model used by Organizations that want to have the highest level of control of the data, application and OS they move or create on the Cloud Service Provider (CSP). Here the CSP is responsible only for building the datacenter; provide the connectivity and power; create and administer the HW assets where the Customer will put the data/application/os on. So, with this model, the Customer has the greater amount of control but... something is still missing. Customer should ask some questions:

• Who controls the Supply chain?
• Are the technicians trained and skilled enough to secure the HW layer?
• Are the physical entrances secured?
• Are the security policies applied by the Cloud Provider in-line with the Organization's policy?
• Are the logs coming from the HW layer collected and secured in a safe manner?

2. Platform as a Service (PaaS): in this model, the Customer loses the controls of the Infrastructure layer and OS layer. Indeed, the Cloud Service Provider installs, maintains and administers the OS. The OS layer is secured by the CSP by using its internal security policy. In this model, in addition to the IaaS model, other questions from the Cloud Customer side arise:

• Is the OS layer secured in accordance with my internal security policy?
• If the OS layer is too restrictive, will my Applications run without any problem?
• If there is a vulnerability in the OS layer, how much time does the CSP spend to apply the patch?
• OS logs can collect even application logs and information, are these information collected, shared or archived in some way by the CSP?

3. Software as a Service (SaaS): most of the controls are ceded to the Provider. Customer moves and creates the data on the new cloud platform. The Customer is ultimately responsible for any unauthorized disclosure of PII (Personal Identifiable Information) in the Cloud. There are no contracts or clauses that remove/cover this responsibility. Funny, eh? Customers using this layer will ask themselves:

• Is the Application we are using patched/hardened/controlled?
• Does the provider have access to my data?
• Am I able to encrypt the data in the application?
• If the data is encrypted by the provider, who manages the keys?
• Who takes care about the backup? How long is the retention?

For all the models, there are several security questions that would come into mind, such as:

• People are the weakest point of the chain. Does the Provider perform background checks? Are "Separation of Duties, Mandatory Vacation, Least privileges, and Job Rotation" principles applied?
• In case of a breach, does the Provider communicate the incident to the Customers?
• Lock-in: data is moved in the Cloud and the CSP will store data by using its format. What happens to data if the Customer wants to move away?
• Lock-out: Providers are Organizations and they can go out of business in any case. What happens to our data?
• Multi-tenant: data from different customers are stored "together". Are the separation implemented correctly? What happens if there are security holes/vulnerabilities?

The list of questions is long and should become longer during the Business Impact Analysis (BIA). As an Organization, do not move to any Cloud model before you can understand the risks of each one.

Adherence to Standards like ISO, Contracts and SLAs should cover your questions and more. Make sure to read carefully the contract your Cloud Provider is offering to you. Do not sign it without first conducting a BIA and make sure to engage a Cloud Security Architect. Moving too fast to the Cloud can be tricky and can cost a huge amount of money. Upload data in the Cloud can be free but downloading the data from the Cloud to move to another Cloud Provider or to move back to On-Premise have some costs. READ THE CONTRACT and ENCRYPT YOUR DATA!

Luciano Ferrara - Security Architect @Maleva

Personally Identifiable Information (PII) is a legal term pertaining to information security environments. While PII has several formal definitions, generally speaking, it is information that can be used by organizations on its own or with other information to identify, contact, or locate a single person, or to identify an individual in context.

Non-sensitive PII can be transmitted in unsecure form without causing harm to an individual. Sensitive PII must be transmitted and stored in secure form, for example, using encryption, because it could cause harm to an individual, if disclosed.

Organizations use the concept of PII to understand which data they store, process and manage that identifies people and may carry additional responsibility, security requirements, and in some cases legal or compliance requirements.

Blog: Top Challenges to Implementing Data Privacy: Nailing Down Discovery and Classification First is Key.

Personally Identifiable Information (PII) in Privacy Law

PII and similar terms exist in the legislation of many countries and territories:

• In the United States, the National Institute of Standards and Technology (NIST)’s Guide to Protecting the Confidentiality of Personally Identifiable Information defines “personally identifiable” as information like name, social security number, and biometric records, which can be used to distinguish or trace an individual’s identity.
• In the European Union, directive 95/46/EC defines “personal data” as information which can identify a person via an ID number, or factors specific to physical, physiological, mental, economic, cultural or social identity.
• In Australia, the Privacy Act 1988 defines “personal information” as information or an opinion, whether true or not, about an individual whose identity is apparent, or can reasonably be ascertained—a much broader definition than in most other countries.
• In New Zealand, the Privacy Act defines “personal information” as any piece of information that relates to a living, identifiable human being, including names, contact details, financial health, and purchase records.
• In Canada, the Personal Information Protection and Electronic Documents Act (PIPEDA) and Privacy Act defines “personal information” as data that on its own, or combined with other pieces of data, can identify an individual.

What Qualifies as PII?

According to the NIST PII Guide, the following items definitely qualify as PII, because they can unequivocally identify a human being: full name (if not common), face, home address, email, ID number, passport number, vehicle plate number, driver’s license, fingerprints or handwriting, credit card number, digital identity, date of birth, birthplace, genetic information, phone number, login name or screen name.

What Is Considered PII?

Beyond these clear identifiers, there are “quasi identifiers” or “pseudo identifiers” which, together with other information, can be used to identify a person. For example, according to a US governmental study, 87% of the US population can be uniquely identified by a combination of gender, ZIP code and date of birth. Pseudo identifiers may not be considered PII under United States legislation, but are likely to be considered as PII in Europe.

Who is Responsible for Safeguarding PII?

From a legal perspective, the responsibility for protecting PII is not solely attributed to organizations; responsibility may be shared with the individual owners of the data. Companies may or may not be legally liable for the PII they hold.

However, according to a study by Experian, 42% of consumers believe it is a company’s responsibility to protect their personal data, and 64% of consumers said they would be discouraged from using a company’s services following a data breach. In light of the public perception that organizations are responsible for PII, it is a widely accepted best practice to secure PII. A common and effective way to do this is using a Data Privacy Framework.

Creating a Data Privacy Framework

A Data Privacy Framework is a documented conceptual structure that can help businesses protect sensitive data like payments, personal information, and intellectual property. The framework specifies how to define sensitive data, how to analyze risks affecting the data, and how to implement controls to secure it.

While there are established data privacy frameworks such as the Payment Card Industry Data Security Standard (PCI DSS), the ISO 27000 family of standards, and the EU General Data Protection Regulation (GDPR), there are benefits to creating a custom framework for your organization.

A custom Data Protection Framework will help you put an emphasis on the most sensitive and valuable data within your organization, and design controls that are suitable for your organizational structure, culture, regulatory requirements, and security budget.

Follow the steps below to create a custom Data Privacy Framework.

Classification

Define, assess and classify PII your organization receives, stores, manages, or transfers. For each type of PII, identify:

• The required level of confidentiality
• How sensitive the data is to integrity—what happens if it is lost or corrupted
• How important it is to have the data available at all times
• What level of consent has the organization received in relation to the data

Assessment

Conduct a Privacy Impact Assessment (PIA) to determine, for each type or classification or PII, how it is collected, where it is stored, and how it is disposed of, as well as the potential security risks for each type of PII.

Compliance Environment

• Define your legislative obligations for PII compliance in the territories your organization operates in
• Identify voluntary standards you need to comply with, such as PCI DSS
• Determine your organization’s security and liability policy with regard to third party products and services—for example, cloud storage services

PII Security Controls

The Data Privacy Framework should define which security controls the organization needs to have in place to prevent data loss or data leak:

• Change Management—tracking and auditing changes to configuration on IT systems which might have security implications, such as adding/removing user accounts.
• Data Loss Prevention—implementing systems that can track sensitive data transferred within the organization or outside it, and identify unnatural patterns that might suggest a breach.
• Data masking—ensuring that data is stored or transmitted with the minimal required details for the specific transaction, with other details masked or omitted.
• Ethical walls—implementing screening mechanisms to prevent certain departments or individuals within an organization from viewing PII that is not relevant to their work, or that might create a conflict of interest.
• Privileged user monitoring—monitoring all privileged access to files and databases, user creation and newly granted privileges, blocking and alerting when suspicious activity is detected.
• Sensitive data access auditing—in parallel to monitoring activities by privileged users, monitoring and auditing all access to sensitive data, blocking and alerting on suspicious or anomalous activity.
• Secure audit trail archiving—ensuring that any activity conducted on or in relation to PII is audited and retained for a period of 1-7 years, for legal or compliance purposes, and also to enable forensic investigation of security incidents.
• User rights management—identifying excessive, inappropriate, or unused user privileges and taking corrective action, such as removing user accounts that have not been used for several months.
• User tracking—implementing ways of tracking user activity, online and while using organizational systems, to identify negligent exposure of sensitive data, compromise of user accounts, or malicious insiders.

Solution Spotlight: Sensitive and Personal Data Security.