Facebook will not allow users to “opt out” of its face recognition feature.
Facebook will not allow users to “opt out” of its face recognition feature.
From a backdoor placed in the Webmin utility to vulnerability disclosure drama around zero-days in Valve’s Steam gaming clients, Threatpost breaks down this week’s top stories.
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:
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:
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.
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.
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:
McAfee has a three-pronged approach to addressing and mitigating these concerns:
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.
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.”
It’s true that since that publication, the CNIL issued a €50 million fine against Google, 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.
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. 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.”
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 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.”
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.
 Eduardo Ustaran – The Work Ahead. https://www.linkedin.com/pulse/gdpr-work-ahead-eduardo-ustaran/
 Article 40 of the GDPR
 Article 5.6 of the Code
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.)