Gmail - Do I *NEED* Encrypted Email Add-on for GDPR Compliance?

[JRA]

Hi all, sorry if this is a painful question. I'm not DPO here, but want to keep very much on top of things which *could* become my problem.

 

In all fairness, I've asked similar here, but I thought I'd stick this particular question here.

 

We use gmail here and our DPO (and also SLT) would like us to be able to send encrypted emails with gmail, but the reasoning for it is GDPR compliance. As the date for compliance creeps closer I'd rather have something in place if we'll defo need it.

 

Do we *need* to do so? If so, is anyone using anything in particular? We're looking at a couple (Virtru aren't replying, GAME I've only just contacted, Google are doing S/MIME 'any day now' but never today.)

 

Thanks for any bones thrown!

[crc-ict]

Virtru is interesting to deal with. You have to deal with them through online meetings, and they will make you have a preliminary 'meeting' with a pre-screening person before you can even speak to a salesperson. They are very reluctant to tell you pricing - it took three online meetings including a full demo before I got a price out of them. When you get the price, the reason becomes apparent - it is VERY expensive. They also only work in 'office hours' in US Eastern Time, so don't open until about 2pm UK time.

 

Based on that, we decided to not implement e-mail encryption, covering GDPR with policies to say that no personal data should be sent in an e-mail, unless inside an attached, passworded and encrypted Office document or protected PDF. A pain in the butt for users, but given the very high (annual) ost of the encryption software, we couldn't justify any other approach financially.

Edited May 8, 2018 by crc-ict

[djrscally]

Honestly, I'd say you need it. I think the inconvenience of writing an email as a password-protected word file or PDF is a high enough usability barrier that you will find people simply don't bother (maybe not initially, but in 6 months or so for sure). Security needs to be as transparent and easy as possible, or it swiftly falls by the wayside; so whilst I think you could do that as an interim measure I don't think it should be your long term solution.

 

Google is a tough one. There's free plugins but they invariably use PGP which is perfect for sending mail to people who know what they're doing, and useless for recipients who don't. Even S/MIME isn't a great option because it relies on recipients setting up and publishing their public keys, which is pretty unlikely frankly. It's weird they haven't built in a system already to be honest.

[Edutech98]

There is nothing in the 1998 DPA or GDPR that says you *need*to encrypt email – it all comes down to risk analyses and what you deem as an accepted amount of risk.

 

I believe email sent via Gmail is now defaulted to TLS and it will warn you if the email is being sent where TLS is not enabled. There is a risk in that Google processes your email and holds the encryptions keys but unless you are dealing with top secret security then I reckon most companies will accept this risk.

 

Where encryption of email traffic is used there are still other risks, for example if the member of staff can access emails on their phone then this might be a higher risk than the risk of a man in the middle attack so you’d want to spend the time/money on resolving that risk first.

 

If might be worth drilling down what risk he/she is actually trying to mitigate against, and if other risks are there that are more of a threat.

[FN-GM]

You can force email to be sent via TLS. We do that for certain domains or if the word "secure" is in the subject.

 

Thanks

[JRA]

You can force email to be sent via TLS. We do that for certain domains or if the word "secure" is in the subject.

 

Thanks

 

Ah, now, yes I recall you also mentioned this in my other thread (thanks again btw!)

 

How have you experienced life on the network with it? Do things bounce back from the other side often? Operationally, how has it been?

[JRA]

...Also also, how exactly have you set that up if I might ask? All I've got (from Apps > G Suite > Settings for Gmail > Advanced > OU > content compliance) is the option to enable TLS for a list of domains. I definitely like the sound of typing "SECURE" (all caps too) at the start of a message to TLS-ify it!

[FN-GM]

Ah, now, yes I recall you also mentioned this in my other thread (thanks again btw!)

 

How have you experienced life on the network with it? Do things bounce back from the other side often? Operationally, how has it been?

 

It has been great. Every reasonable organisation seems to have TLS working. We have it forced for all gov.uk domains.

 

It doesn't work with BT Internet though.

 

I will get some screenshots of that I have setup. It sounds similar to what you have.

[Edu-IT]

If an email is encrypted is there then any further need to password it etc or is encryption sufficient to be 'compliant'?

[FN-GM]

If an email is encrypted is there then any further need to password it etc or is encryption sufficient to be 'compliant'?

 

Just the TLS encryption is fine. It ensures that it is sent securely during transit.

[Edutech98]

If an email is encrypted is there then any further need to password it etc or is encryption sufficient to be 'compliant'?

 

I try too always drill home that there is not one thing that you can do that will make you “compliant”.

 

The TLS protocol will provide privacy and data integrity of the email whilst it is in transit so this will mitigate against attacks such as man in the middle attacks. Once the email is received by the client, it is no longer encrypted so there are other risks that you will need to think about.

 

For example can emails be opened on personal devices, how do you prevent/manage this, do attachments need to be password protected etc. A lot of data breaches come from attachments containing personal data being sent to the wrong person, so encryption/password protection of the attachment could mitigate this risk. Just because the email was sent over TLS wouldn’t help in this example.

Edited May 9, 2018 by Edutech98

[FN-GM]

For example can emails be opened on personal devices, how do you prevent/manage this,

 

It is not up to the sender to prevent or manage this. The sending organisation has taken the correct steps by sending it via a secure method. It its now up to the recipient to manage the security of the data they process.

 

If you used other encryption with the scenario above you will still have the same problem. Password protecting files isn't good either the recipient can remove the password or copy and paste the contents into something else.

Edited May 9, 2018 by FN-GM

[crc-ict]

Honestly, I'd say you need it. I think the inconvenience of writing an email as a password-protected word file or PDF is a high enough usability barrier that you will find people simply don't bother (maybe not initially, but in 6 months or so for sure). Security needs to be as transparent and easy as possible, or it swiftly falls by the wayside; so whilst I think you could do that as an interim measure I don't think it should be your long term solution.

 

I see your point there, but even a high-cost solution like Virtru will only provide that transparent security on the sending side (unless your recipient also happens to be using Virtru). It's all very well being able to encrypt an e-mail with a click of a button from your end, but it's not so good if your recipient cannot or will not accept having to go through a third-party portal or install third-party plugins to be able able read the message.

 

Our decision making was based on the very small actual real-world risk of an email being intercepted by some unknown man-in-the-middle (especially as most gmail goes using TLS anyway), against the much more realistic risk of an e-mail being sent to the wrong person in error - something that solutions like Virtru do nothing to prevent as there is no further authentication once it has been delivered. So we couldn't justify spending thousands annually to mitigate a very small risk when it wouldn't help with a realistically much larger risk.

[enjay]

I will get some screenshots of that I have setup. It sounds similar to what you have.

 

Notes on how you set that up in GMail would be epic - emails leaving us to social services etc. is one thing we're conscious of, as there is no way to avoid them containing personal information, and since we ditched Outlook we can't use things like Egress.

[Edutech98]

It is not up to the sender to prevent or manage this. The sending organisation has taken the correct steps by sending it via a secure method. It its now up to the recipient to manage the security of the data they process.

 

If you used other encryption with the scenario above you will still have the same problem. Password protecting files isn't good either the recipient can remove the password or copy and paste the contents into something else.

 

I was thinking internal email rather than sending externally. So for example an internal member of staff sends an internal email that contains an attachment. The attachment contains a list of SEN students. The person accesses their emails on their own phone with no passcode enabled. The phone is lost/stolen and someone could then access this data. The school would be responsible for this, they would be asked what risk assessment was done for staff accessing emails on their phone. That the email was sent over TLS would be irrelevant in this situation. Encryption of the attachment would help in this example, or staff training on the dangers of sending attachments with personal data, or MDM enrolled phones with enforced passcodes, or no email on personal devices procedures.

 

It may be helpful for the TS to do a DPIA so they can identify the risks, then they can look at what measures can be put in place to protect against the risks they have identified. One of the risks would be MITM attacks, which TLS would mitigate.

[FN-GM]

I was thinking internal email rather than sending externally. So for example an internal member of staff sends an internal email that contains an attachment. The attachment contains a list of SEN students. The person accesses their emails on their own phone with no passcode enabled. The phone is lost/stolen and someone could then access this data. The school would be responsible for this, they would be asked what risk assessment was done for staff accessing emails on their phone. That the email was sent over TLS would be irrelevant in this situation. Encryption of the attachment would help in this example, or staff training on the dangers of sending attachments with personal data, or MDM enrolled phones with enforced passcodes, or no email on personal devices procedures.

 

It may be helpful for the TS to do a DPIA so they can identify the risks, then they can look at what measures can be put in place to protect against the risks they have identified. One of the risks would be MITM attacks, which TLS would mitigate.

 

You can force encryption and pin codes on mobile devices that have Gmail / Office 365 added. That is what we have done for years.

[Edutech98]

You can force encryption and pin codes on mobile devices that have Gmail / Office 365 added. That is what we have done for years.

 

Yep my old trust used to use Google Apps and that’s what we did. Staff had a choice – if you want staff emails on your personal mobile phone then it needs to be enrolled in the Google Apps MDM. If you don’t want to enrol your phone, that’s fine but you can’t access school emails on it. We got it put in to a policy that was signed by all staff and reviewed every year.

 

I don’t think schools get much value for money buying encryption to encrypt data in transit when TLS is fine for schools imo. There are other more likely risks when using email that TLS/encryption in transit will not mitigate that should be addressed though. I always get the feeling that a lot of non technical people hear “email is encrypted” and then they don’t think about the other risks to email that are much more likely to occur because they don't actually understand what encryption in transit actually means and what it protects against.

Edited May 9, 2018 by Edutech98

[JRA]

You can force email to be sent via TLS. We do that for certain domains or if the word "secure" is in the subject.

 

Thanks

 

Mr FN-GM if you do manage to point me in the direction of where you've set that up by subject-line text you'll be my new hero. Like Batman or something.

 

If I manage to find it myself beforehand though I'll stick them up.

 

EDIT - Oh wait wait! It's in the "Content compliance" bit I think, with it's own lil tickbox! I'm gonna play...

 

MORE EDIT - Aight so we do this in Apps > G Suite > Settings for Gmail > Advanced settings > scroll down to Compliance section then Content compliance. It's all really simple in there tbh, so what I've done is outbound rule that looks for "SECURE" (I'm talking ALL CAPS here) at the start of the subject to force TLS (tickbox at the bottom, but explore the options ofc.)

 

The benefit of all this is to force TLS, and if the other end doesn't support that, bounce the email back to sender. Google verified this would happen in chat, but I wanted to confirm with my own two eyes.

 

To test, I guessed the best thing is to try sending something to somewhere that does support TLS, and to somewhere that doesn't. Hotmail does, seems to work ok, temp-mail.org gives you a throwaway account that definitely doesn't, and I do get a bounce message and all works as it should.

Edited May 10, 2018 by JRA

[mjk]

here is a free encryption addon for google, useful for key staff - senco etc

https://flowcrypt.com/

[JRA]

here is a free encryption addon for google, useful for key staff - senco etc

https://flowcrypt.com/

Cheers - yes I'd spotted that before, but we'd need more than 100 tbh and their group pricing is a fair bit.

 

Defo worth a look if you've 100 employees though.

[mavhc]

nna play...

 

MORE EDIT - Aight so we do this in Apps > G Suite > Settings for Gmail > Advanced settings > scroll down to Compliance section then Content compliance. It's all really simple in there tbh, so what I've done is outbound rule that looks for "SECURE" (I'm talking ALL CAPS here) at the start of the subject to force TLS (tickbox at the bottom, but explore the options ofc.)

 

The benefit of all this is to force TLS, and if the other end doesn't support that, bounce the email back to sender. Google verified this would happen in chat, but I wanted to confirm with my own two eyes.

 

To test, I guessed the best thing is to try sending something to somewhere that does support TLS, and to somewhere that doesn't. Hotmail does, seems to work ok, temp-mail.org gives you a throwaway account that definitely doesn't, and I do get a bounce message and all works as it should.

 

Question is, what happens if you force TLS for everything, does enough stuff break to make it too painful?

[mjk]

Question is, what happens if you force TLS for everything, does enough stuff break to make it too painful?

 

I would have thought so, schools email all sorts of companies/other schools and not all of them have techs on hand to setup this type of thing. It's easy with Google/365 but many would have setup and onsite exchange 5yrs ago and misconfigured it.

You can choose to just send TLS to specific domains - like your local authority, certain other schools etc which is a half way house.

[JRA]

Question is, what happens if you force TLS for everything, does enough stuff break to make it too painful?

Remains to be seen tbh. I know gmail tries to use TLS currently but fails back to non-secured if the other side doesn't support it. I have a funny feeling BT email is the only 'big' thing that doesn't support it now, but I've not done huge amounts of reading on it just yet. In fact, finding something that didn't support TLS for the real-world testing was a bit of a challenge!

 

Forcing it on for absolutely everything (if I did so) probably wouldn't, in this modern world, be too much of a problem. He says...

 

Longer-term we'll be going with Google's S/MIME but this fills the gap for us as it stands now.

[djrscally]

Remains to be seen tbh. I know gmail tries to use TLS currently but fails back to non-secured if the other side doesn't support it. I have a funny feeling BT email is the only 'big' thing that doesn't support it now, but I've not done huge amounts of reading on it just yet. In fact, finding something that didn't support TLS for the real-world testing was a bit of a challenge!

 

Forcing it on for absolutely everything (if I did so) probably wouldn't, in this modern world, be too much of a problem. He says...

 

Longer-term we'll be going with Google's S/MIME but this fills the gap for us as it stands now.

 

Does S/MIME let you set a password to open emails? I thought it was key based auth only.

[mjk]

It is fairly easy to test this because TLS will fail before a 550 error so just email [email protected] and see if you get a TLS failure or a 550.