The EU GDPR and Cloud: Six Must-Dos to Comply

December 4, 2015 | Leave a Comment

By Krishna Narayanaswamy, Co-founder and Chief Scientist, Netskope

You don’t have to be European to care about the European Commission’s pending EU General Data Protection Regulation (GDPR). Set to be adopted in 2017 and implemented the following year, carrying penalties up to 5 percent of an enterprise’s global revenues, and replacing the current Data Protection Directive and all country-level data privacy regulations, this pending law should matter to any organization that has European customers. The purpose of the GDPR is to protect citizens’ personal data, increase the responsibility and accountability of organizations that process data (and ones that direct them to do so), and simplify the regulatory environment for businesses.

The information technology community has been abuzz on the topic for some time now. What’s been missing from the conversation up to now, however, is the cloud and how that throws a wrench into the GDPR mix. One of the biggest trends over the last decade is shadow IT. According to our latest Netskope Cloud Report, the average enterprise is using 755 cloud apps. In Europe, it’s 608. Despite increased awareness over the last year or so, IT and security professionals continue to underestimate this by 90 percent or more. This is shadow IT at its finest. So the big question is whether organizations that only know about 10 percent of the cloud apps in use can really ensure compliance with the GDPR?

CSA-GDPR-6-Questions

We partnered with legal and privacy expert, Jeroen Terstegge, a partner with Privacy Management Partners in the Netherlands who specializes in data privacy legislation. He helped us make sense of the pending GDPR as it relates to cloud, and identified six things cloud-consuming organizations need to do to comply if they serve European customers (this is all fleshed out in this white paper, by the way):

  1. Know the location where cloud apps are processing or storing data. You can accomplish this by discovering all of the cloud apps in use in your organization and querying to understand where they are hosting your data. Hint: The app vendor’s headquarters are seldom where your data are being housed. Also, your data can be moved around between an app’s data centers.
  2. Take adequate security measures to protect personal data from loss, alteration, or unauthorized processing. You need to know which apps meet your security standards, and either block or institute compensating controls for ones that don’t. The Cloud Security Alliance’s Cloud Controls Matrix (CCM) is a perfect place to start. Netskope has automated this process by adapting the CCM to the most impactful, measurable set of 45+ parameters with our Cloud Confidence Index, so you can easily see where apps are lacking and quickly compare among similar apps.
  3. Close a data processing agreement with the cloud apps you’re using. Once you discover the apps in use in your organization and consolidate those with overlapping functionality, sanction a handful and execute a data processing agreement with them to ensure that they are adhering to the data privacy protection requirements set forth in the GDPR.
  4. Collect only “necessary” data and limit the processing of “special” data. Specify in your data processing agreement (and verify in your DLP policies) that only the personal data needed to perform the app’s function are collected by the app from your users or organization and nothing more, and that there are limits on the collection of “special” data, which are defined as those revealing things like race, ethnicity, political conviction, religion, and more.
  5. Don’t allow cloud apps to use personal data for other purposes. Ensure through your data processing agreement, as well as verify in your app due diligence, that apps state clearly in their terms that the customer owns the data and that they do not share the data with third parties.
  6. Ensure that you can erase the data when you stop using the app. Make sure that the app’s terms clearly state that you can download your own data immediately, and that the app will erase your data once you’ve terminated service. If available, find out how long it takes for them to do this. The more immediate (in less than a week), the better, as lingering data carry a higher risk of exposure.

Of course, if you end up accomplishing some of these steps via policy, make sure you can take action whether your users are on-premises or remote, on a laptop or mobile device, or on a managed or BYOD device.

This week we announced the availability of a toolkit that includes a couple of services and several complimentary tools to help our community understand and comply with the GDPR. You can access it here.

Cloud apps are useful for users, and often business-critical for organizations. Blocking them – even the shadow ones – would be silly at this point. Instead, follow the above six steps to bring your cloud app usage into compliance with the GDPR.

Network Segmentation and Its Unintended Complexity

December 3, 2015 | Leave a Comment

By Kevin Beaver, Guest Blogger, Lancope

analyticsLook at the big security regulations, i.e. PCI DSS, and any of the long-standing security principles and you’ll see that network segmentation plays a critical role in how we manage information risks today. The premise is simple: you determine where your sensitive information and systems are located, you segment them off onto an area of the network that only those with a business need can access and everything stays in check. Or does it?

When you get down to specific implementations and business needs, that’s where complexity comes into the picture. For instance, it may be possible to segment off critical parts of the network on paper but when you consider variables such as protocols in use, web services links, remote access connections and the like, you inevitably come across distinct openings in what was considered to be a truly cordoned-off environment.

I see this all the time in my work performing security assessments. The network diagram shows one thing yet the vulnerability scanners and manual analysis paint a different picture. Digging in further and simply asking questions such as the following highlight what’s really going on:

  • How are servers, databases and applications designed to communicate with one another?
  • Who can really access the segmented environment? How does that access take place?
  • What areas of the original system had to be changed to accommodate a technical or business need?
  • What information is being gathered across the network segment in terms of network and security analytics and what is that information really telling us?
  • What else are we forgetting?

Getting all of the key players involved such as database administrators, network architects, developers and even outside vendors that support systems running in these network segment(s) and asking questions such as these will often reveal what’s really going on beyond what’s documented or what’s assumed. This is not a terrible situation in and of itself. The systems need to work the way they need to work and business needs to get done. However, this exercise highlights a new level of network complexity that was otherwise unknown – or at least unacknowledged.

This leads me to my final point that’s obvious yet needs to be repeated: complexity and security don’t go well together. It’s a direct relationship – the more complexity that exists in your network environment, the more out of control you’re going to be. I’m confident that if we looked at the root causes of most of the known security breaches uncovered by reports such as the Cisco 2015 Annual Security Report and publicized on websites such as the Privacy Rights Clearinghouse Chronology of Data Breaches, we’d see that network complexity was instrumental in facilitating those incidents.

Putting aside politics, lack of budget and all the other common barriers to an effective information security program, you cannot secure what you don’t acknowledge. If vulnerabilities exist in your network segmentation, threats will surely come along and find a way to take advantage. It’s your job to figure out where the weaknesses are among the complexity of your network segmentation so you can minimize the impact of any attempted exploits moving forward. Otherwise, regardless of the levels of security visibility and analytics you might have, your systems will remain fair game for attack.

Kevin Beaver is an information security consultant, expert witness and professional speaker with Atlanta-based Principle Logic, LLC.

Good and Bad News on Safe Harbour: Take a Life Ring or Hold Out for a New Agreement?

December 1, 2015 | Leave a Comment

By Susan Richardson, Manager/Content Strategy, Code42

liferingIf your organization relied on the now-invalid Safe Harbour agreement to legally transfer data between the U.S. and the EU, there’s good news and bad news.

The good news? The European Commission just threw you some life rings. The governing body issued a guidance Nov. 6 that outlines alternative mechanisms for legally continuing transatlantic data transfers:

Standard contractual clauses
Sometimes referred to as model clauses, standard contractual clauses are boilerplate provisions for specific types of data transfers, such as between a company and a vendor. They’re often the least costly on a short-term basis.

Binding corporate rules for intra-group transfers
These allow personal data to move freely among the different branches of a worldwide corporation. Sounds easy, but the process can be time-consuming and expensive, depending on the scope of the company. That’s because the rules have to be approved by the Data Protection Authority (DPA) in each member state from which you want to transfer data.

Derogation where contractually necessary
This exception allows for data transfers that are required to fulfill a contractual obligation. For example, when a travel agent sends details of a flight booking to an airline.

Derogation for legal claims
This exception allows for data transfers that are required to process a legal claim.

Derogation based on individual consent
Legal folks say this option isn’t a slam dunk. Many DPAs have ruled that it’s not possible to obtain meaningful consent from employees, given the lopsided nature of the employer-employee relationship. On the consumer side, it may be difficult to demonstrate that consumers provided meaningful consent if the relevant notice is embedded in a lengthy privacy policy they may never read. Data privacy experts at law firm BakerHostetler recommend a click-through privacy policy with an “I agree” checkbox, as opposed to a browsewrap privacy policy that implies consent by virtue of the consumer simply using the website, app or service.

The bad news? You only have until the end of January 2016 to get the new mechanisms in place before DPAs start investigating and enforcing transfer violations. Or you could hedge your bets and hold out for U.S. and EU negotiators to hammer out a Safe Harbour 2.0 agreement by then, as they’ve committed to do.

After all, the U.S. House of Representatives did surprise everyone by quickly passing the baseline requirement for moving forward on October 20th: the Judicial Redress Act would give EU citizens some rights to file suit in the States for U.S. government misuse of their data. It was received in the Senate and referred to the Committee on the Judiciary on October 21.