- Getting to the GDPR: Four key use cases to jumpstart your efforts, from IBM.
- Preparing for the General Data Protection Regulation (GDPR), from UK’s Information Commissioner’s Office.
- Data protection self assessment toolkit, also from the UK’s ICO.
Here are a few things to get you started with European Union General Data Protection Regulation (GDPR). First is a little introduction:
After four years of preparation and debate the GDPR was finally approved by the EU Parliament on 14 April 2016. It will enter in force 20 days after its publication in the EU Official Journal and will be directly application in all members states two years after this date. Enforcement date: 25 May 2018 – at which time those organizations in non-compliance will face heavy fines.
The EU General Data Protection Regulation (GDPR) replaces the Data Protection Directive 95/46/EC and was designed to harmonize data privacy laws across Europe, to protect and empower all EU citizens data privacy and to reshape the way organizations across the region approach data privacy.
And now a few key points from the Frequently Asked Questions page:
Who does the GDPR affect?
The GDPR not only applies to organisations located within the EU but it will also apply to organisations located outside of the EU if they offer goods or services to, or monitor the behaviour of, EU data subjects. It applies to all companies processing and holding the personal data of data subjects residing in the European Union, regardless of the company’s location.
What are the penalties for non-compliance?
Organizations can be fined up to 4% of annual global turnover for breaching GDPR or €20 Million. This is the maximum fine that can be imposed for the most serious infringements e.g.not having sufficient customer consent to process data or violating the core of Privacy by Design concepts. There is a tiered approach to fines e.g. a company can be fined 2% for not having their records in order (article 28), not notifying the supervising authority and data subject about a breach or not conducting impact assessment. It is important to note that these rules apply to both controllers and processors — meaning ‘clouds’ will not be exempt from GDPR enforcement.
What constitutes personal data?
Any information related to a natural person or ‘Data Subject’, that can be used to directly or indirectly identify the person. It can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer IP address.
Interesting, right? Have a nice day now.
Here’s an interactive collection of the world’s biggest data breaches. It goes back to 2004, where about 92,000,000 email addresses and screen names were stolen by an AOL employee, and covers most of the major events up until and including 2016. There are a few ways to filter the data and change the representation.
Overall, should give you a pretty good idea of how safe and secure your online data is. Oh, and how private it is too.
Here are some interesting news on the subject of Google and HTTPS:
In support of our work to implement HTTPS across all of our products (https://www.google.com/transparencyreport/https/) we have been operating our own subordinate Certificate Authority (GIAG2), issued by a third-party. This has been a key element enabling us to more rapidly handle the SSL/TLS certificate needs of Google products.
As we look forward to the evolution of both the web and our own products it is clear HTTPS will continue to be a foundational technology. This is why we have made the decision to expand our current Certificate Authority efforts to include the operation of our own Root Certificate Authority. To this end, we have established Google Trust Services (https://pki.goog/), the entity we will rely on to operate these Certificate Authorities on behalf of Google and Alphabet.
The process of embedding Root Certificates into products and waiting for the associated versions of those products to be broadly deployed can take time. For this reason we have also purchased two existing Root Certificate Authorities, GlobalSign R2 and R4. These Root Certificates will enable us to begin independent certificate issuance sooner rather than later.
We intend to continue the operation of our existing GIAG2 subordinate Certificate Authority.
If you need a bit of help putting this into perspective, this Hacker News thread has your back:
You can now have a website secured by a certificate issued by a Google CA, hosted on Google web infrastructure, with a domain registered using Google Domains, resolved using Google Public DNS, going over Google Fiber, in Google Chrome on a Google Chromebook. Google has officially vertically integrated the Internet.
The last few weeks were super busy at work, so I accidentally let a few SSL certificates expire. Renewing them is always annoying and time consuming, so I was pushing it until the last minute, and then some.
Instead of going the usual way for the renewal, I decided to try to the Let’s Encrypt deal. (I’ve covered Let’s Encrypt before here and here.) Basically, Let’s Encrypt is a new Certification Authority, created by Electronic Frontier Foundation (EFF), with the backing of Google, Cisco, Mozilla Foundation, and the like. This new CA is issuing well recognized SSL certificates, for free. Which is good. But the best part is that they’ve setup the process to be as automated as possible. All you need is to run a shell command to get the certificate and then another shell command in the crontab to renew the certificate automatically. Certificates are only issued for 3 months, so you’d really want to have them automatically updated.
It took me longer than I expected to figure out how this whole thing works, but that’s because I’m not well versed in SSL, and because they have so many different options, suited for different web servers, and different sysadmin experience levels.
Eventually I made it work, and here is the complete process, so that I don’t have to figure it out again later.
We are running a mix of CentOS 7 and Amazon AMI servers, using both Nginx and Apache. Here’s what I had to do.
First things first. Install the Let’s Encrypt client software. Supposedly there are several options, but I went for the official one. Manual way:
# Install requirements yum install git bc cd /opt git clone https://github.com/certbot/certbot letsencrypt
Alternatively, you can use geerlingguy’s lets-encrypt-role for Ansible.
Secondly, we need to get a new certificate. As I said before, there are multiple options here. I decided to use the certonly way, so that I have better control over where things go, and so that I would minimize the web server downtime.
There are a few things that you need to specify for the new SSL certificate. These are:
- The list of domains, which the certificate should cover. I’ll use example.com and www.example.com here.
- The path to the web folder of the site. I’ll use /var/www/vhosts/example.com/
- The email address, which Let’s Encrypt will use to contact you in case there is something urgent. I’ll use firstname.lastname@example.org here.
Now, the command to get the SSL certificate is:
/opt/letsencrypt/certbot-auto certonly --webroot --email email@example.com --agree-tos -w /var/www/vhosts/example.com/ -d example.com -d www.example.com
When you run this for the first time, you’ll see that a bunch of additional RPM packages will be installed, for the virtual environment to be created and used. On CentOS 7 this is sufficient. On Amazon AMI, the command will run, install things, and will fail with something like this:
WARNING: Amazon Linux support is very experimental at present... if you would like to work on improving it, please ensure you have backups and then run this script again with the --debug flag!
This is useful, but insufficient. Before you can run successfully, you’ll also need to do the following:
yum install python26-virtualenv
Once that is done, run the certbot command with the –debug parameter, like so:
/opt/letsencrypt/certbot-auto certonly --webroot --email firstname.lastname@example.org --agree-tos -w /var/www/vhosts/example.com/ -d example.com -d www.example.com --debug
This should produce a success message, with “Congratulations!” and all that. The path to your certificate (somewhere in /etc/letsencrypt/live/example.com/) and its expiration date will be mentioned too.
If you didn’t get the success message, make sure that:
- the domain, for which you are requesting a certificate, resolves back to the server, where you are running the certbot command. Let’s Encrypt will try to access the site for verification purposes.
- that public access is allowed to the /.well-known/ folder. This is where Let’s Encrypt will store temporary verification files. Note that the folder starts with dot, which in UNIX means hidden folder, which are often denied access to by many web server configurations.
Just drop a simple hello.txt to the /.well-known/ folder and see if you can access it with the browser. If you can, then Let’s Encrypt shouldn’t have any issues getting you a certification. If all else fails, RTFM.
Now that you have the certificate generated, you’ll need to add it to the web server’s virtual host configuration. How exactly to do this varies from web server to web server, and even between the different versions of the same web server.
For Apache version >= 2.4.8 you’ll need to do the following:
SSLEngine on SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
For Apache version < 2.4.8 you’ll need to do the following:
SSLEngine on SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem
For Nginx >= 1.3.7 you’ll need to do the following:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
You’ll obviously need the additional SSL configuration options for protocols, ciphers and the like, which I won’t go into here, but here are a few useful links:
- Apache Configuration Example
- How To Secure Nginx with Let’s Encrypt on Ubuntu 14.04
- Certbot User Guide
- Using the webroot domain verification method
- Guide to Deploying Diffie-Hellman for TLS
Once your SSL certificate is issued and web server is configured to use it, all you need is to add an entry to the crontab to renew the certificates which are expiring in 30 days or less. You’ll only need a single entry for all your certificates on this machine. Edit your /etc/crontab file and add the following (adjust for your web server software, obviously):
# Renew Let's Encrypt certificates at 6pm every Sunday 0 18 * * 0 root (/opt/letsencrypt/certbot-auto renew && service httpd restart)
That’s about it. Once all is up and running, verify and adjust your SSL configuration, using Qualys SSL Labs excellent tool.
With all the security breaches going around, it’s hard to keep track on which sites got broken into, what was stolen, and, most importantly, if you are affected. have i been pwned? website provides a very simple interface to check if your account data was leaked, across more than a hundred websites.
Try it out … you might be surprised. Like I was. :)
I’ve first written about Let’s Encrypt back in November 2014. It hasn’t been that long ago, but boy, what a journey!
WhatsApp introduces end-to-end encryption for all communications – chats, pictures, videos, etc. I’m sure it’ll help them get more individuals and businesses on the network, as well as probably ban the app in a handful of countries.
WhatsApp has always prioritized making your data and communication as secure as possible. And today, we’re proud to announce that we’ve completed a technological development that makes WhatsApp a leader in protecting your private communication: full end-to-end encryption. From now on when you and your contacts use the latest version of the app, every call you make, and every message, photo, video, file, and voice message you send, is end-to-end encrypted by default, including group chats.
The idea is simple: when you send a message, the only person who can read it is the person or group chat that you send that message to. No one can see inside that message. Not cybercriminals. Not hackers. Not oppressive regimes. Not even us. End-to-end encryption helps make communication via WhatsApp private – sort of like a face-to-face conversation.
Reddit user ThatOnePrivacyGuy compiled this Google sheet with comparison of 130 VPN services.
It covers a whole lot of metrics for each – from pricing, encryption and configuration options to additional services, activism and jurisdiction. Enjoy!
Updated (May 22, 2017): If you want to learn more about different VPN providers, have a look at Anonymster.com.
Here are a couple of quotes from the “You are your phone” article:
Even obscure variables such as how frequently a user recharges the phone’s battery, how many incoming text messages they receive, how many miles they travel in a given day or how they enter contacts into their phone — the decision to add last name correlates with creditworthiness — can bear on a decision to extend credit.
The test subjects used their phones more than five hours a day, on average. Much of that usage went on unconsciously, the researchers found. When the subjects were asked to estimate how often they checked their phone during a day, the average answer was 37 times. The tracking data revealed, however, that the subjects actually used their phones 85 times a day on average, more than twice as often as they thought.
It’s an interesting read, though not too surprising.