Few users on corporate systems can say that they have never regretted sending an email to a distribution list, and tell something that was just meant for one person. Luckily many email systems will default to send back to just the originator of the email, but mistakes can often still happen, and many users receive emails which reveal a little too much information on the distribution list. Personally I have seen many emails which are send with a To: list which include many email addresses who should be kept private.
Forgetting to Blind Copy
So the yesterday, the Gardai had to apologise for data breach which released over 1,700 email addresses, and which was blamed on an ‘administrative error’. A particular problem with this is when an email is to be sent to a contact list, and where they are supposed to be sent through a blind carbon copy (BCC:) and by mistake end up on a carbon copy (CC:) list. Most users understand the difference, and known that a BCC: version does not release the full distribution list. Care must be taken if an email is sent to a person, and they do not known that it includes a BCC list, and then one of the users on the list sends back an email to in the To: field, which can cause some embarrassment for the reason for the BCC distribution (the person on the BCC is meant to know that it’s a secret distribution). Often the method used is to set the sender of the email to being both the sender and receiver of the email, and all others on the BCC: list.
The data breach happened within Dublin North Central Gardaí when they sent our their community policing information bulletin to their distribution list, but did not hide recipients’ addresses to others. This is seen as a breach of Ireland’s data protection laws related to the leak of personal data. While they tried to recall it, the mechanisms for recall often do not work, once the email has left the local system, as they user is often prompted as to whether they want to delete it or not. Like it or not, most users actually view the email, even though the sender has tried to recall it.
Also, the recall can actually make the breach worse, especially onto non-Microsoft Exchange servers, as the To: field will also include the email addresses of the users who where sent the email in the first place, doubling the impact. Luckily there wasn’t any sensitive information in the newsletter, but the email distribution list included the email addresses of others in the community.
This is an unfortunately mistake, and apart from user training, there are many solutions to this. The best solution is to avoid BCC altogether, and use an emailing system which takes a list, and then sends the email to each address on the list, and then checks the outgoing emails so that there is no other possibilities for data leakage.
Along with this, in sensitive environments, back-end email systems should check the number of users in the CC: or TO: fields to make sure there are not too many setup. It can also be avoided by buffering emails by taken the client off-line, and then getting others to check the email before it is sent.
Data breach was unfortunate, especially as the newsletter was a key mechanism in engaging with the local community. It would be hoped that there is not a knee-jerk reaction to this in the Gardia, and that the engagement continues, but where future breaches are avoided with improved procedures.
Few users can say that they have never made a mistake in sending an email, so this must be acknowledged in this case – as mistakes happen. The key thing is that organisations need to set in-place safeguards, in order to protect themselves, and for large-scale data breaches.
As much as possible, users need to be careful when sending to large-scale distribution list (such as across a whole organisation), as a single Reply All can result in a great deal of embarrassment, along with a great deal of annoyance.