EU GDPR vs US: What Is Personal Data?

 

By Rich Campagna, Chief Marketing Officer, Bitglass

GDPR-personal data screen shotMay 25, 2018—GDPR enforcement day,—has come and gone with little fan fare (and about 6 quadrillion privacy policy updates), but that doesn’t mean we all know what to do to get into compliance. In fact, some measures put only one third of organizations in compliance as of the deadline, and the linked article refers to UK organizations—what about US organizations that are only now catching on to the fact that they probably need to be GDPR compliant? We thought that contrasting GDPR with typical US regulations and definitions would be helpful.

It’s personal. Or, is it?

First topic, what constitutes personal data?

In the US, when we hear “personal data,” that usually equates to Personally Identifiable Information (PII). PII, according to the CIO of the US Navy, is “information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, including any other personal information which is linked or linkable to a specified individual.” This has become an important enough topic that NIST has created a list of specific fields that constitute PII.

GDPR: It’s more than PII

How does this differ from how personal data is defined in GDPR?

Well, according to the GDPR, personal data means “any information relating to an identified or identifiable natural person.”

Side note: In GDPR, “natural persons” are typically referred to as, “data subjects,” which is the least personal and least natural possible way to describe natural persons that I can think of, but I digress…

GDPR clarifies that “identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

In other words, personal information includes the US definition of PII, but goes much further. In addition to PII, personal information can include IP address (yes, even dynamic IPs with user behind a router doing NAT/PAT), sexual preference, medical prescriptions, occupation, eye color, shoe size and puzzling fandom of the band Survivor.

That’s lesson #1 – personal data, as defined by GDPR, goes far further than the typical US definition of PII.

More to come in future posts…

 

 

What Is a CASB?

By Dylan Press, Director of Marketing, Avanan

Email is the #1 attack vector. Cloud Account Takeover is the #1 attack target.
A CASB is the best way to protect against these threats.

cartoon of man asking What is a CASBGartner first defined the term Cloud Access Security Broker (CASB) in 2011, when most IT applications were hosted in the data center and few companies trusted the cloud. Most online services were primarily aimed at the consumer. At the time, CASB products were designed to provide visibility for so-called Shadow IT and limit employee access to unauthorized cloud services.

Today, organizations have embraced the cloud, replacing many of their datacenter applications with Software as a Service (SaaS) or moving much of their IT into infrastructure (IaaS) providers like Amazon or Azure. Instead of limiting access, CASBs have evolved to protect cloud-hosted data and provide enterprise-class security controls so that organizations can incorporate SaaS and IaaS into their existing security architecture.

CASBs provide four primary security services: Visibility, Data Security, Threat Protection, and Compliance. When comparing CASB solutions you should first make sure that they meet your needs in each of these categories.

Visibility

A CASB identifies all the cloud services (both sanctioned and unsanctioned) used by an organization’s employees. Originally, this only included the services they would use directly from their computer or mobile device, often called “Shadow IT“. Today, it is possible for an employee to connect an unsanctioned SaaS directly to a an approved SaaS via API. This “Shadow SaaS” requires more advanced visibility tools.

Shadow IT Monitoring: Your CASB must connect to your cloud to monitor all outbound traffic for unapproved SaaS applications and capture real-time web activity. Since nearly all SaaS applications send your users email notifications, your CASB should also scan every inbox for rogue SaaS communication to identify unapproved accounts on an approved cloud services.

Shadow SaaS Monitoring: Your CASB must connect to your approved SaaS and IaaS providers to monitor third-party SaaS applications that users might connect to their account. It should identify both the service as well as the level of access the user has provided.

Risk Reporting: A CASB should assess the risk level for each Shadow IT/Shadow SaaS connection, including the level of access each service might request (i.e. read-only access to a calendar might be appropriate, read-write access to email might not.) This allows you to make informed decisions and prioritize the applications that need immediate attention.

Event Monitoring: Your CASB should provide information about real-time and historical events in all of your organization’s SaaS applications. If you do not know how the applications are being used, you can not properly control them or properly assess the threats facing your organization.

Data Security

A CASB enforces data-centric security policies by offering granular access controls or encryption. It incorporates role-based policy tools, data classification and loss prevention technologies to monitor user activity and audit, block or limit access. Once, these were stand-alone systems. Today it is vital that they are integrated into the organization’s data policy architecture.

Data Classification: Your CASB should identify personally identifiable information (PII) and other confidential text within every file, email or message. Taking this further, it should be capable of applying policies to control how that sensitive information can be shared.

Data-Centric Access Management: Your CASB should allow you to manage file permissions based upon the user’s role and the type of data the file contains using cloud-aware enforcement options that work within the context of the cloud service.

Policy-based Encryption: Your CASB should be able to encrypt sensitive information across all your cloud services to ensure data security, even after files leave the cloud.

Threat Protection

A CASB protects cloud services from unwanted users or applications. This might include real time malware detection, file sandboxing or behavior analytics and anomaly detection. New threats require new protections, so the list should include anti-phishing, account-takeover detection and predictive (A.I.) malware technologies.

Anti-phishing Protection: Phishing attacks are the #1 source of data breaches every year, but few CASBs offer phishing protection for cloud-based email. For a technology that is protecting your cloud environment, anti-phishing is a must. It has been proven over and over again that your email provider is not a viable solution to the phishing problem.

Account Takeover Protection: Your CASB should monitor every user event (not just logins) to identify anomalous behavior, permission violations, or configuration changes that indicated a compromised account.

URL Filtering: Your CASB should check every email, file, and chat messages for malicious links.

Real Time Malware Detection: Your CASB should scan every email and file for active code and malicious content before it reaches the inbox.

Advanced Threat Sandboxing: Your CASB should test suspicious files in an emulation environment to detect and stop zero-day threats.

Compliance

Regulated organizations require auditing and reporting tools to demonstrate data compliance and a CASB should provide all the necessary auditing and reporting tools. More advanced solutions offer policy controls and remediation workflows that enforce regulatory compliance in real time for every industry, from GDPR and SOX to PCI and HIPAA..

SIEM Integration: Your CASB should collect and correlate user, file and configuration events from each cloud application installed in your organization’s environment and make them visible through your organization’s existing reporting infrastructure.

Auditing: Your CASB should have access to historical event data for retrospective compliance auditing as well as real-time reporting.

Enforcement: Your CASB should be able to move and encrypt files, change permissions, filter messages or use any number of cloud-native tools to ensure compliance through automated policies.

Email Security from Your CASB

As you may have noticed, across all the CASB criteria, email security is a major component. Can this really be that important? After all, so few CASBs include email security.

No matter the motivation, email continues to be the most common vector for enterprise breaches. Phishing and pretexting represented 98% of social incidents and 93% of breaches last year. Protection for the cloud must include protection for cloud-based email. Without cloud-based email security, a CASB is not truly providing full cloud security and is just acting as a simple Shadow IT tool.

Conclusion

While a solution doesn’t need to have every feature mentioned in this blog post in order to sell themselves as a CASB, they are the criteria that separate the CASBs that are complete security solutions from those that will need to be paired with additional security tools. If you want a CASB to act as your full security suite protecting your organization from cloud-borne threats then this will serve as a useful checklist.

Cloud Security Trailing Cloud App Adoption in 2018

By Jacob Serpa, Product Marketing Manager, Bitglass

In recent years, the cloud has attracted countless organizations with its promises of increased productivity, improved collaboration, and decreased IT overhead. As more and more companies migrate, more and more cloud-based tools arise.

In its fourth cloud adoption report, Bitglass reveals the state of cloud in 2018. Unsurprisingly, organizations are adopting more cloud-based solutions than ever before. However, their use of key cloud security tools is lacking. Read on to learn more.

The Single Sign-On Problem

Single sign-on (SSO) is a basic, but critical security tool that authenticates users across cloud applications by requiring them to sign in to a single portal. Unfortunately, a mere 25 percent of organizations are using an SSO solution today. When compared to the 81 percent of companies that are using the cloud, it becomes readily apparent that there is a disparity between cloud usage and cloud security usage. This is a big problem.

The Threat of Data Leakage

While using the cloud is not inherently more risky than the traditional method of conducting business, it does lead to different threats that must be addressed in appropriate fashions. As adoption of cloud-based tools continues to grow, organizations must deploy cloud-first security solutions in order to defend against modern-day threats. While SSO is one such tool that is currently underutilized, other relevant security capabilities include shadow IT discoverydata loss prevention (DLP), contextual access control, cloud encryptionmalware detection, and more. Failure to use these tools can prove fatal to any enterprise in the cloud.

Microsoft Office 365 vs. Google’s G Suite

Office 365 and G Suite are the leading cloud productivity suites. They each offer a variety of tools that can help organizations improve their operations. Since Bitglass’ 2016 report, Office 365 has been deployed more frequently than G Suite. Interestingly, this year, O365 has extended its lead considerably. While roughly 56 percent of organizations now use Microsoft’s offering, about 25 percent are using Google’s. The fact that Office 365 has achieved more than two times as many deployments as G Suite highlights Microsoft’s success in positioning its product as the solution of choice for the enterprise.

The Rise of AWS

Through infrastructure as a service (IaaS), organizations are able to avoid making massive investments in IT infrastructure. Instead, they can leverage IaaS providers like Microsoft, Amazon, and Google in order to achieve low-cost, scalable infrastructure. In this year’s cloud adoption report, every analyzed industry exhibited adoption of Amazon Web Services (AWS), the leading IaaS solution. While the technology vertical led the way at 21.5 percent adoption, 13.8 percent of all organizations were shown to use AWS.

To gain more information about the state of cloud in 2018, download Bitglass’ report, Cloud Adoption: 2018 War.

Majority of Australian Data Breaches Caused by Human Error

By Rich Campagna, Chief Marketing Officer, Bitglass

world mapIt wasn’t long ago that the first breach under the Office of the Australian Information Commissioner’s (OAIC) Privacy Amendment Bill was made public. Now, OAIC is back with their first Quarterly Statistics Report of Notifiable Data Breaches. While the report doesn’t offer much in the way of detail, it does highlight a couple of interesting trends.

The statistic that jumps out most is that of the 63 reported breaches in this first (partial) quarter, the majority (51%) were the result of “human error.” According to OAIC, “human error may include inadvertent disclosures, such as by sending a document containing personal information to the incorrect recipient.” Sounds like too few Australian organizations are controlling things like external sharing, even though sharing (and many other potentially risky activities) can be controlled quite easily with a Cloud Access Security Broker (CASB).

human error leading cause of breaches

The report also breaks down number of breaches by industry. Health service provides had the misfortune of leading the charge in this initial quarter, representing nearly a quarter of breaches. Healthcare organizations have a particularly difficult task with data protection. On one hand, they have a very mobile workforce that requires immediate access to data, from anywhere and from any device. On the other hand, medical records are some of the most valuable sources of personal data, including not only medical history, but personal information, financial information, and more.

healthcare most breaches

Fortunately, this first quarter didn’t include any large, “mega-breaches,” as more than half involved the personal information of fewer than 10 individuals, and 73% involving fewer than 100 individuals.

most breaches small

It will be interesting to see whether schemes like this, and the upcoming GDPR, have an impact on overall data protection outcomes.

Cloud App Encryption and CASB

 

By Kyle Watson, Partner/Information Security, Cedrus Digital

man staring at bulletin boardMany organizations are implementing Cloud Access Security Broker (CASB) technology to protect critical corporate data stored within cloud apps. Amongst many other preventative and detective controls, a key feature of CASBs is the ability to encrypt data stored within cloud apps. At the highest level, the concept is quite simple – data flowing out of the organization is encrypted, as it is stored in the cloud. However, in practice there are nuances in the configuration options that may have impact on how you implement encryption in the cloud. This article outlines important architectural decisions to be made prior to the implementation of encryption solutions through a CASB.

Gateway Delivered, Bring Your Own Key (BYOK), or Vendor Encryption

There are three generic methods in cloud-based encryption.

Gateway delivered encryption – In this model, the CASB may integrate with your organization’s existing key management solution through Key Management Interoperability Protocol (KMIP) or provide a cloud-based key management solution. In either case, the keys used to encrypt your data never leave your CASB.

  • Data is encrypted before it leaves your environment and is stored at the vendor
  • You control the keys
  • The vendor retains no capability to access your data

BYOK encryption – In this model, the keys are generated and managed by your organization, and then are supplied to the vendor. BYOK allows you to manage the lifecycle of the keys, which are then shared with the vendor. This includes revoking and rotating keys. The keys are then provided to and utilized by the vendor to decrypt requested data for use by authorized users. CASB can be involved as a broker of the keys to simplify, centralize, and streamline the process of key management by allowing you to perform this administration directly in the CASB User Interface (UI). This also may be done using KMIP with your existing key management solution. Alternatively, without a CASB you may still enjoy the benefits of encryption with your own keys, but administration would be manual on an app-by-app basis.

  • Data is encrypted at the vendor
  • You can control the keys
  • The vendor retains the capability to access your data

Vendor provided encryption – In this model, the vendor provides keys and key management. The administration may be provided through user interfaces provided by the vendor. The CASB is not involved.

  • Data is encrypted at the vendor
  • The vendor controls the keys
  • The vendor retains the capability to access your data

Important Considerations

There is not a “best” way to manage encryption for cloud apps. One important consideration for you to make the best decisions for your company begins with your motivation. Is your primary concern compliance, mitigating risk of vendor compromise, protecting data from being disclosed in blind subpoenas, all three?

  • Compliance – Encryption for compliance can be met easily by any of the three approaches, and is simplest with vendor provided encryption.
  • Mitigating risk of vendor compromise – Using encryption to mitigate the risk of vendor compromise implies the need to manage your own key, since your data will not be accessible without the key. Gateway delivered encryption is the approach that can provide the highest level of risk mitigation due to vendor compromise, as your keys never leave your environment. Cyber- attackers stealing your data will not be able to decrypt it without using your key or breaking your encryption. Risk may also be mitigated through BYOK, but agreements must be secured from the vendor to communicate breaches in a timely fashion. Then you must take appropriate revocation actions in your key management process.
  • Protecting data from being disclosed in subpoenas / blind subpoenas – Using encryption to protect data from being disclosed in subpoenas also implies the need to manage your own key. Gateway delivered encryption is the approach that can provide the highest level of risk mitigation from blind subpoena through a completely technical means, as third parties retrieving your data will not be able to decrypt it without your key. Risk may also be mitigated through BYOK, but agreements must be secured from the vendor to communicate third-party requests for your data in a timely fashion. Then you must take appropriate revocation actions in your key management process.

Unstructured and Structured Data

To further explain these approaches we must break out two very different types of data prevalent in the cloud: Unstructured and structured data. Unstructured data refers to data generated and stored as unique files and is typically served through end user apps, for example, Microsoft Word documents. Structured data refers to data that conforms to a data model and is typically served through relational databases and User Interfaces (UI), for example, Salesforce UI.

Structured Data

  • Gateway delivered encryption – Since the CASB sits between your end user and the application, structured data can represent a challenge to usability. From a usability perspective, whenever the application vendor changes field structures, the encryption must be addressed in order to maintain usability. From a security perspective, the app must decrypt and reveal some information in order to allow search, sort, and type-ahead fields to work properly in a cloud app UI. This is known as “Format Preserving”, “Order Preserving”, and “Order Revealing” encryption, which can lower the overall standard. A growing body of research is challenging this method and exposing weaknesses that may lead to compromise. For example, if you were to type “JO” in a field and it revealed all of the persons with names beginning with JO, this data has to be retrieved decrypted to support the UI.
  • BYOK encryption – since you supply the keys to the vendor, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. From a security perspective, BYOK does not suffer from the same risk of compromise in “reveal”, as exists in gateway delivered encryption.
  • Vendor provided encryption – Since the vendor owns the keys, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. From a security perspective, vendor provided encryption does not suffer from the same risk of compromise in “reveal”, as exists in gateway delivered encryption.

Unstructured Data

  • Gateway delivered encryption – Risk of usability problems is low on unstructured data in cloud storage. However, an important consideration is key rotation. Data encrypted under one set of keys can only be opened with those keys. Keys may need to remain available in archive, for reads, even if they have been retired.
  • BYOK encryption – Since the keys are supplied to the vendor, encryption/decryption occurs within the vendor application architecture as does key rotation and management.
  • Vendor provided encryption – Since the vendor owns the keys, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. Key management processes will be dependent upon the vendor.

Industry Direction

Most major cloud vendors are moving toward the support of a BYOK model. Some of these include Salesforce, ServiceNow, Box, Amazon Web Services (AWS), and Microsoft Azure to name a few. As more and more vendors are offering this type of capability, at Cedrus we believe that this is the direction of cloud encryption.

Opinion

  • Gateway delivered encryption – This is the highest level of security that can be provided when it comes to cloud app encryption, but may have an impact to the business in usability issues, especially when applied to structured data. High-risk apps and data are safest in this configuration and require the most care and feeding.
  • BYOK encryption – This implementation can provide a very high level of security without the impact that comes with gateway encryption. Through integration with a CASB as a broker of keys to centralize this management, this solution provides an excellent balance between protection and usability for high-risk apps and data.
  • Vendor provided encryption – This implementation provides a much higher level of security than not implementing encryption. This solution may be best suited for apps and data of lower criticality or meeting compliance requirements, only.

Recommendations

As with all security decisions, risk and compliance must be the yardstick in any decision. Since we do not know the industry, application, or risk to your business; this is a generic recommendation.

Where possible, always leverage your own keys over vendor-provided keys. Remember, a breach into a lower-risk app may provide clues to breach other apps.

When provided as an option, the best trade-off between security and usability is BYOK. It is very important to gain agreement from vendors for proactive communication. Where BYOK is not offered, the risks must be weighed carefully between vendor provided and gateway delivered encryption, especially for structured data.

When considering a move to gateway encryption, risk analysis of the app and data are critical. The risk of compromise should be clear and present danger. This is because a decision to move to gateway encryption for structured data means a commitment to the management and maintenance at a much higher level than BYOK or vendor provided encryption. This is not a recommendation against taking this course, but advice to consider this path carefully and plan the resources necessary to maintain this type of implementation. In a recent exchange with a customer they articulated the challenge: “We use CASB to provide field level encryption for our Salesforce instance. There are many issues requiring a lot of support and we have plans to move away from it and leverage encryption that is part of the Salesforce platform.”