1

In my career I've spent a lot of time implementing security, and a lot of time exasperated at how users obviate my security by e-mailing attachments of sensitive information.

I'm thinking primarily of CSVs, Excel spreadsheets and PDFs that are exported by systems and delivered securely initially (e.g. over HTTPS), but then e-mailed insecurely by users to each other.

I cannot find any information on a (IETF?) standard to 'tag' files as being unsafe to send over e-mail. Many file systems and file types allow metadata to be attached to a file (e.g. author). Why isn't there some standard metadata that says 'file contains confidential information' that e-mail programs would recognise and refuse to allow as attachments?

  • 2
    because the user can save a local copy and email that - unless you mean that each and every file type needs to include an IETF-like metadata tagging system? – schroeder Oct 18 '17 at 11:07
  • 2
    and you would not have to tag as 'unsafe' but to encode a data classification into the metadata, then have all systems agree on how to handle different classes of data – schroeder Oct 18 '17 at 11:08
  • 1
    This kind of system is Data Loss Prevention - DLP. Not aware of any standards but there are many products. They aim to protect primarily against user error but sometimes catch hackers – paj28 Oct 19 '17 at 21:12
5

Simply put, it would be a great deal of work to implement for negligible real-world gain.

Let's imagine for a moment that such a "standard" mechanism for meta data describing the confidentiality level of a particular file existed and we are able to hand-wave away the technical details implementing such a mechanism across multiple file formats, operating systems, mail servers, clients etc.

Someone is going to be ultimately responsible for setting that information on a per file basis and, logically that is going to be the people creating/working with these files.

So, Joe Bloggs in accounting has been working on the company's quarterly figures in Excel for the last week or so, and like the diligent employee he is he has ticked the box to indicate that this is "Confidential" information. Satisfied with the job well done and certain that as soon as Mr Grand Boss the CEO sees his detailed and colorful pie charts he'll be getting that raise he's been hoping for, so he attaches the completed Excel file to a new e-mail and hits send. Outlook refuses to send the mail though, because the attachment is marked as "Confidential" and sending such files is forbidden.

Joe still needs to get these figures to the CEO though so does he:

a) Look into some way he can encrypt the file? He's heard the word in movies before but doesn't really know what it means, or where to start.

or

b) open the file, un-tick the "Confidential" box and re-attach it to the e-mail.

I can almost guarantee that in 99% of cases it's going to be option B, and that's not someone who is trying to circumvent security. They are just trying to do their job.

For someone who is trying to circumvent it, to send confidential information and documents to competitors or whoever for nefarious purposes. Then if they have the permissions to modify the file they will remove the confidential flag, send the mail and then re-enable it. Even if all they have is read access they will open the file and copy-paste the contents into a fresh one and send it.

So in either of those scenarios the "Confidential" flag has done precisely nothing to increase security

4

Opt-in systems are bad. There's nothing that enforces such protection; one can always just use an email client / document viewer that ignores those restrictions. (I believe the "Okulus" PDF viewer software still has a checkmark somewhere in its settings for "respect DRM in documents"; it's unchecked by default.) Circumventing such systems is easy; you can edit the file (or its metadata), or put it in some kind of wrapper (like a ZIP archive or tarball) that conceals the metadata, or change the extension to something that doesn't store metadata the same way, and the client's filters won't catch it.

Where do you store the metadata? Some file systems allow "extended attributes" or "alternate data streams" or similar, but many don't, especially ones like the ubiquitous FAT variants used for nearly all removable storage. Even when the file systems do support such structures, they usually aren't compatible across file systems, so standards would need to be created, and developers would need to check for, a huge array of ways a file could be marked. Some file types allow storing that sort of data internally, as part of the file itself, but that's definitely not going to work for simple plain-text formats like CSV, and is never going to be universal; you might get something that works for MS Office files (which do in fact have a range of metadata fields and their standardized format) but not for Open Office formats (ODT, etc.) which don't have that in their standards, and substantially more different file types like audio recordings would store such metadata differently if at all.

Basically, it would be a ton of effort for very little return and the implementation would always have holes anyhow (when a new format rises to prominence, or a new communication system is adopted, or whatever).

  • You make many good points. However the conclusion you reach is pretty bleak: that there is nothing that can be done about this (in my opinion) significant, industry-wide security problem. Let us posit that if a user isn't tech savvy enough to understand that e-mail is insecure, then they aren't tech savvy enough to deliberately circumvent anything. Accepting that premise, is there still nothing that can be done? – Richard Kennard Oct 18 '17 at 6:52
  • 3
    The standard thing at that point is to monitor outbound traffic for internal documents. It's far from perfect and arguably a bit intrusive, but is generally considered a valid security option for companies. Other options include denying the user access to the file itself (make them view and/or edit it through a web portal or remote-access-only editor), using a very restricted selection of software and file formats for which meaningful DRM controls do exist, using OS-level restrictions to prohibit write-capable removable storage and unapproved software, and - of course - education. – CBHacking Oct 18 '17 at 7:33
  • 1
    It's worth noting that email is not inherently insecure, by the way; if I'm connecting to my work email from home, the connection is often just as secure as doing it from work. My home computer may itself be less secure, of course. Sending a document to a private email account is insecure in the sense that the controller of that email system (Google, for Gmail) could access the message and document, but in practice the popular systems (Gmail, etc.) are also quite secure against outside attacks. Not that this isn't a valid concern, but I think you're overestimating the email risk. – CBHacking Oct 18 '17 at 7:36
  • 1
    @RichardKennard - If the user isn't tech savvy enough to understand e-mail is insecure they shouldn't be able to use email on a system which gives them read access to sensitive documents. Its pretty easy to have a "do not email anything you wouldn't leave on the bus" policy and if you catch anyone breaking it treat them as if they had left confidential documents on a bus.. – Hector Oct 18 '17 at 8:07
3

With a few exceptions (most notably DMARC), email standards are woefully ignored and we're stuck in a world of whatever the common email servers and clients will support, for better or worse (mostly worse). This is comparable to the way the web worked back when Netscape Navigator and Internet Explorer were the top browsers, though pretty assuredly permanent.

Therefore, it's up to the big players to dictate terms to the rest. Google has actually done this to a degree, decreeing that there are certain file formats that GMail will refuse to send:

File types you can't include as attachments [at GMAIL]

.ADE, .ADP, .BAT, .CHM, .CMD, .COM, .CPL, .EXE, .HTA, .INS, .ISP, .JAR, .JS (NEW), .JSE, .LIB, .LNK, .MDE, .MSC, .MSI, .MSP, .MST, .NSH .PIF, .SCR, .SCT, .SHB, .SYS, .VB, .VBE, .VBS, .VXD, .WSC, .WSF, .WSH

I see .CSV, .XLS, and similar formats as being too common for blocking wholesale. .PDF is extremely important as it's the only reliable document format if you need to ensure consistent rendering (like for publishing proofs, marketing, or resumes).

There are solutions out there that perform data leakage protection to combat exfiltration issues, and there are other solutions out there that will pay special attention to document formats with executable aspects (like macros and embedded flash). I think those are the easiest way to do this sort of thing, though I'm biased (the email security solution I work on offers these things).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.