Data Security

mcafee-10730-b2b-retouched-20180516_72dpi-300x200.jpg

Data Residency: A Concept Not Found In The GDPR

Data Residency: A Concept Not Found In The GDPR

Are you facing customers telling you that their data must be stored in a particular location?

Be reassured: As a processor of data, we often encounter a discussion about where the data is resident, and we are often facing people certain that their data must be stored in a given country. But the truth is, most people don’t have the right answer to this legal requirement.

To understand the obligations and requirements surrounding data storage, you first need to understand the difference in concepts between “data residency” and “data localization.”

What Are Data Residency and Data Localization?

Data residency is when an organization specifies that their data must be stored in a geographical location of their choice, usually for regulatory, tax or policy reasons. By contrast, data localization is when a law requires that data created within a certain territory stays within that territory.

People arguing that data must be stored in a certain location are usually pursuing at least one of the following three objectives:

  1. To allow data protection authorities to exert more control over data retention and thereby have greater control over compliance.
  2. In the EU, it is seen as means to encourage data controllers to store and process data within the EU or within those countries deemed to have the same level of data protection as in the EU, as opposed to moving data to those territories considered to have less than “adequate” data protection regimes. The EU has issued only 13 adequacy decisions: for Andorra, Argentina, Canada (commercial organizations), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Switzerland, US (Privacy Shield only) and Uruguay.
  3. Finally, it is seen by some as a tool to strengthen the market position of local data center providers by forcing data to be stored in-country.

However, it is important to note that accessing personal data is considered a “transfer” under data protection law—so even if data is stored in Germany (for example), if a company has engineers in India access the data for customer service or support purposes, it has now “moved” out of Germany. Therefore, you can’t claim “residency” in Germany if there is access by a support function outside the country. Additionally, payment processing functions also sometimes occur in other countries, so make sure to consider them as well. This is an important point that is often missed or misunderstood.

Having understood the concept of data residency and data localization, the next question is, are there data residency or localization requirements under GDPR?

In short: No. GDPR does not introduce and does not include any data residency or localization obligations. There were also no data residency or localization obligations under the GDPR’s predecessor, the Data Protection Directive (95/46/EC). In fact, both the Directive and the GDPR establish methods for transferring data outside the EU.

Having said that, it is important to note that local law may impose certain requirements on the location of the data storage (e.g., Russia’s data localization law, German localization law for health and telecom data, etc.).

So, if there is no data residency or localization requirement under GDPR, can we transfer the data to other locations?

The GDPR substantially repeats the requirements of the Data Protection Directive, which states that you need to have legal transfer means if you move data outside of the EU into a jurisdiction with inappropriate safeguards (see map here). The legal transfer means are:

  • Adequacy— A decision by the EU Commission that a country has adequate protection level;
  • Binding Corporate Rules— Binding internal rules of a company to be approved by data protection authorities;
  • Standard Contractual Clauses / Model Clauses—Individually negotiated contracts between controller and processor
  • Privacy Shield— For US companies only; this is a replacement self-certification program for the Safe Harbor.

I have heard that Privacy Shield and Standard Contractual Clauses are under serious scrutiny? What is this all about?

Following the European Court of Justice decision that the EU-US Safe Harbor arrangement does not provide adequate protection for the personal data of EU data subjects, the EU and US entered into a new arrangement to enable the transfer of data (the Privacy Shield). However, a number of non-governmental organizations and privacy advocates have started legal action to seek decisions that the Privacy Shield and the EU Standard Contractual Clauses do not provide sufficient protection of data subjects’ personal data.

It remains to be seen how the European Court of Justice will decide in these cases. They are expected to rule on these matters by the end of 2019.

I have heard that the Standard Contractual Clauses/Model Clauses might be updated.  What is that all about? 

In order to protect data being transferred outside of the European Union, the Union issued three Standard Contractual Clause templates (for controller to controller transfers and for controller to processor transfers). These have not been updated since they were first introduced in 2001, 2004 and 2010, respectively. However, the European Union’s consumer commissioner, under whom privacy falls, has indicated that the EU is working on an updated version of the Standard Contractual Clauses. It remains to be seen how the Clauses will be modernized and whether the shortcomings, concerns and gripes of existing Standard Contractual Clauses will be addressed to the satisfaction of all parties.

One thing is for certain, however—the data protection space will only get more attention from here on out, and those of us working in this space will have to become more accustomed to complexities such as those surrounding Data Residency.

 

This blog is for information purposes only and does not constitute legal advice, contractual commitment or advice on how to meet the requirements of any applicable law or achieve operational privacy and security. It is provided “AS IS” without guarantee or warranty as to the accuracy or applicability of the information to any specific situation or circumstance. If you require legal advice on the requirements of applicable privacy laws, or any other law, or advice on the extent to which McAfee technologies can assist you to achieve compliance with privacy laws or any other law, you are advised to consult a suitably qualified legal professional. If you require advice on the nature of the technical and organizational measures that are required to deliver operational privacy and security in your organization, you should consult a suitably qualified privacy professional. No liability is accepted to any party for any harms or losses suffered in reliance on the contents of this publication.

 

The post Data Residency: A Concept Not Found In The GDPR appeared first on McAfee Blogs.

McAfee_business_medical_2female_doctor_patient_hospital_72dpi-300x200.jpg

Data Privacy and Security Risks in Healthcare

Data Privacy and Security Risks in Healthcare

Healthcare is a business much like all verticals I work with; however, it has a whole different set of concerns beyond those of traditional businesses. The compounding threats of malware, data thieves, supply chain issues, and the limited understanding of security within healthcare introduces astronomical risk. Walking through a hospital a few weeks ago, I was quickly reminded of how many different devices are used in healthcare—CT scanners, traditional laptops, desktops, and various other devices that could be classified as IoT.

Sitting in the hospital, I witnessed people reporting for treatment being required to sign and date various forms electronically. Then, on a fixed-function device, patients were asked to provide a palm scan for additional biometric confirmation. Credit card information, patient history, and all sorts of other data was also exchanged. In my opinion, patients should be asking, “Once the sign-in process is complete, where is the patient data stored, and who has access to it? Is it locked away, encrypted, or sent to the “cloud” where it’s stored and retrieved as necessary? If it’s stored on the cloud, who has access to that?” I do recall seeing a form asking that I consent to releasing records electronically, but that brings up a whole new line of questions. I could go on and on …

Are these challenges unique to healthcare? I would contend that at some level, no, they’re not. Every vertical I work with has compounding pressures based on the ever-increasing attack surface area. More devices mean more potential vulnerabilities and risk. Think about your home: You no doubt have internet access through a device you don’t control, a router, and many other devices attached to that network. Each device generally has a unique operating system with its own set of capabilities and with its own set of complexities. Heck, my refrigerator has an IP address associated with it these days! In healthcare, the risks are the same, but on a bigger scale. There are lives at stake, and the various staff members—from doctors, to nurses, to administrators—are there to hopefully focus on the patient and the experience. They don’t have the time or necessarily the education to understand the threat landscape—they simply need the devices and systems in the hospital network to “just work.”

Many times, I see doctors in hospital networks and clinics get fed up with having to enter and change passwords. As a result, they’ll bring in their personal laptops to bypass what IT security has put in place. Rogue devices have always been an issue, and since those devices are accessing patient records without tight security controls, they are a conduit for data loss. Furthermore, that data is being accessed from outside the network using cloud services. Teleradiology is a great example of how many different access points there are for patient data—from the referring doctor, to the radiologist, to the hospital, and more.

Data Privacy and Security Risks in Healthcare

Figure 1:  Remote Tele-radiology Architecture

With healthcare, as in most industries, the exposure risk is potentially great. The solution, as always, will come from identifying the most important thing that needs to be protected, and figuring out the best way to safeguard it. In this case, it is patient data, but that data is not just sitting locked up in a file cabinet in the back of the office anymore. The data is everywhere—it’s on laptops, mobile devices, servers, and now more than ever in cloud services such as IaaS, PaaS and SaaS. Fragmented data drives great uncertainty as to where the data is and who has access to it.

The security industry as a whole needs to step up. There is a need for a unified approach to healthcare data. No matter where it sits, there needs to be some level of technical control over it based on who needs access to it. Furthermore, as that data is traversing between traditional data centers and the cloud, we need to be able to track where it is and whether or not it has the right permissions assigned to it.

The market has sped up, and new trends in technology are challenging organizations every day. In order to help you keep up, McAfee for Healthcare (and other verticals) are focusing on the following areas:

  • Device – OS platforms—including mobile devices, Chrome Books and IoT—are increasingly locked down, but the steadily increasing number of devices provides other avenues for attack and data loss.
  • Network – Networks are becoming more opaque. HTTP is rarely used anymore in favor of HTTPS, so the need for a CASB safety net is essential in order to see the data stored with services such as Box or OneDrive.
  • Cloud – With workloads increasingly moving to the cloud, the traditional datacenter has been largely replaced by IaaS and PaaS environments. Lines of business are moving to the cloud with little oversight from the security teams.
  • Talent – Security expertise is extremely difficult to find. The talent shortage is real, particularly when it comes to cloud and cloud security. There is also a major shortage in quality security professionals capable of threat hunting and incident response.

Data Privacy and Security Risks in Healthcare

McAfee has a three-pronged approach to addressing and mitigating these concerns:

  • Platform Approach – Unified management and orchestration with a consistent user experience and differentiated insights, delivered in the cloud.
    • To enhance the platform, there is a large focus on Platform Driven Managed Services—focused on selling outcomes, not just technology.
  • Minimized Device Footprint – Powerful yet minimally invasive protection, detection and response spanning full-stack tech, native engine management and ‘as a service’ browser isolation. This is becoming increasingly important as the typical healthcare environment has an increasing variety of endpoints but continues to be limited in resources such as RAM and CPU.
  • Unified Cloud Security – Spanning data centers, integrated web gateway/SaaS, DLP and CASB. The unification of these technologies provides a safety net for data moving to the cloud, as well as the ability to enforce controls as data moves from on-premise to cloud services. Furthermore, the unification of DLP and CASB offers a “1 Policy” for both models, making administration simpler and more consistent. Consistent policy definition and enforcement is ideal for healthcare, where patient data privacy is essential.

In summary, security in healthcare is a complex undertaking. A vast attack surface area, the transformation to cloud services, the need for data privacy and the talent shortage compound the overall problem of security in healthcare. At McAfee, we plan to address these issues through innovative technologies that offer a consistent way to define policy by leveraging a superior platform. We’re also utilizing sophisticated machine learning to simplify the detection of and response to bad actors and malware. These technologies are ideal for healthcare and will offer any healthcare organization long-term stability across the spectrum of security requirements.

The post Data Privacy and Security Risks in Healthcare appeared first on McAfee Blogs.

McAfee_consumer_1female_headphone_subway_station_72dpi-300x200.jpg

The GDPR – One Year Later

The GDPR – One Year Later

A couple of weeks ago, one famous lawyer blogged about an issue frequently discussed these days: the GDPR, one year later.

The sky has not fallen. The Internet has not stopped working. The multi-million-euro fines have not happened (yet). It was always going to be this way. A year has gone by since the General Data Protection Regulation (Regulation (EU) 2016/679) (‘GDPR’) became effective and the digital economy is still going and growing. The effect of the GDPR has been noticeable, but in a subtle sort of way. However, it would be hugely mistaken to think that the GDPR was just a fad or a failed attempt at helping privacy and data protection survive the 21st century. The true effect of the GDPR has yet to be felt as the work to overcome its regulatory challenges has barely begun.”[1]

It’s true that since that publication, the CNIL issued a €50 million fine against Google,[2] mainly for lacking a clear and transparent privacy notice. But even that amount is purely negligible compared to the fact that just three months before that, Google had been hit with a new antitrust fine from the European Union, totaling €1.5 billion.

So, would we say that despite the sleepless nights making sure our companies were ready to comply with privacy, privacy pros are a bit disappointed by the journey? Or what should be our reaction, as privacy pros, when people around us ask, “Is your GDPR project over now?”

Well, guess what? Just like we said last year, it’s a journey and we are just at the start of this voyage. But in a world where cloud has become the dominant way to access IT services and products, it might be useful to highlight a project to which the GDPR gave birth, the EU Cloud Code of Conduct.[3]

Of course, cloud existed prior to the GDPR and many regulators around the world had given guidance well before the GDPR on how to tackle the sensitivity and the risks arising from outsourcing IT services in the cloud.[4] But before the GDPR, most cloud services providers (CSPs) were inclined to attempt to force their customers (the data controllers) to “represent and warrant” that they would act in compliance with all local data laws, and that they had all necessary consents from data subjects to pass data to the CSP processors pursuant to the services. This scenario, although not sensible under EU data protection law, was often successful, as the burden of non-compliance used to lie solely with the customer as controller.

The GDPR changed that in Recital 81, making processors responsible for the role they also play in protecting personal data. Processors are no longer outside the ambit of the law since “the controller should use only processors providing sufficient guarantees, in particular in terms of expert knowledge, reliability and resources, to implement technical and organizational measures which will meet the requirements of this Regulation, including for the security of processing.

The adherence of the processor to an approved code of conduct or an approved certification mechanism may be used as an element to demonstrate compliance with the obligations of the controller.”[5]

With the GDPR, processors must implement appropriate technical and organizational security measures to protect personal data against accidental or unlawful destruction or loss, alteration, unauthorized disclosure, or access.

And adherence to an approved code of conduct may provide evidence that the processor has met these obligations, which brings us back to the Cloud Code of Conduct. One year after the GDPR, the EU Cloud Code of Conduct General Assembly reached a major milestone in releasing the latest Code version that has been submitted to the supervisory authorities.

The Code describes a set of requirements that enable CSPs to demonstrate their capability to comply with GDPR and international standards such as ISO 27001 and 27018. It also proves that the GDPR has marked a strong shift in the contractual environment.

In this new contractual arena, a couple of things are worth emphasizing:

  • The intention of the EU Cloud Code of Conduct is to make it easier for cloud customers (particularly small and medium enterprises and public entities) to determine whether certain cloud services are appropriate for their designated purpose. It covers the full spectrum of cloud services (SaaS, PaaS, and IaaS), and has an independent governance structure to deal with compliance as well as an independent monitoring body, which is a requirement of GDPR.
  • Compliance to the code does not in any way replace the binding agreement to be executed between CSPs and customers, nor does it replace the right for customer to request audits. It introduces customer-facing versions of policies and procedures that allow customers to know how the CSP works to comply with GDPR duties and obligations, including policies and processes around data retention, audit, sub-processing, and security.

The Code proposes interesting tools to enable CSPs to comply with the requirements of the GDPR. For instance, on audit rights, it states that:

“…the CSP may e.g. choose to implement a staggered approach or self-service mechanism or a combination thereof to provide evidence of compliance, in order to ensure that the Customer Audits are scalable towards all of its Customers whilst not jeopardizing Customer Personal Data processing with regards to security, reliability, trustworthiness, and availability.”[6]

Another issue that often arises when negotiating cloud agreements: engaging a sub-processor is permissible under the requirements of the Code, but it requires—similar to the GDPR—a prior specific or general written authorization of the customer. A general authorization in the cloud services agreement is possible subject to a prior notice to the customer. More specifically, the CSP needs to put in place a mechanism whereby the customer is notified of any changes concerning an addition or a replacement of a sub-processor before that sub-processor starts to process personal customer data.

The issues highlighted above demonstrate the shift in the contractual environment of cloud services.

Where major multinational CSPs used to have a minimum set of contractual obligations coupled with minimum legal warranties, it is interesting to note how the GDPR has been able to drastically change the situation. Nowadays, the most important cloud players are happy to demonstrate their ability to contractually engage themselves. The more influential you are as a cloud player, the more you have the ability to comply with the stringent requirements of the GDPR.

 

[1] Eduardo Ustaran – The Work Ahead. https://www.linkedin.com/pulse/gdpr-work-ahead-eduardo-ustaran/

[2] https://www.cnil.fr/en/cnils-restricted-committee-imposes-financial-penalty-50-million-euros-against-google-llc

[3] https://eucoc.cloud/en/detail/news/press-release-ready-for-submission-eu-cloud-code-of-conduct-finalized/

[4] https://acpr.banque-france.fr/node/30049

[5] Article 40 of the GDPR

[6] Article 5.6 of the Code

The post The GDPR – One Year Later appeared first on McAfee Blogs.

vox-messenger-secure-corpLogo-60x60

End-2-End Encrypted. Secure. Ad-Free.
Lightweight and Faster than the Competition.

Vox Messenger is a secure alternative to other popular chat messenger apps.

Available for Free. Whitelabel Corporate Edition Coming Soon.

All Rights Reserved - Copyright @ 2018 - Vox Messenger (a Division of Kryotech Ltd.)