How to safely use EFSS solutions

Written by thedawidbalut | Published 2017/03/13
Tech Story Tags: security | dropbox | data-governance | file-sharing | file-sync-and-share

TLDRvia the TL;DR App

Shameless plug — If you’re a fan of storytelling, I encourage you to read my previous article which is kind of a preface to this one: Software complexity as an enemy of security.However, it’s not required to know the preface because both of them have an individual value.

I’ve been in EFSS‍ (Enterprise File Sync and Share‍) space for over 4 years already, which I believe makes me qualified to share some observations in terms of EFSS product security. I started my journey in this industry by doing penetration tests and bug hunting for EFSS vendors, and for the last 3.5 years I’ve been working as a security architect‍ for a company that offers exactly that stuff.My goal is to level up security awareness in the EFSS industry, because based on my observations, lots of users are still not aware of all the things they should know.

There is a lot of vendors with fluff-alike content “we have this great feature, it allows you to enable so granular permissions that even you won’t be able to access that data”, and while marketing-wise this may be good, it’s doesn’t provide much technical value with respect to what I want to talk about here.

I failed to find a good resource which describes actual benefits from security features of EFSS so I’m sharing my own content for the benefit of regular users, tech admins and to poke at the vendors a bit*. Maybe someone already produced great content on this subject, and maybe I wasn’t diligent enough in my search, but I assume that if I wasn’t able to find it, regular user won’t waste time to dig deeper.

Here are the biggest players in the EFSS industry to which this guide applies:

During pentests it happens that you can’t break the security of a customer’s core network, but you can access all their confidential data by breaching unsecured 3rd party assets. Breaking into on-premise messaging servers‍ or external data storage is often times much simpler because even admins sometimes have no clue about that little thing they were supposed to configure. It’s the same thing with internal apps, which are known for being less secured than main products for weird legacy culture and poor mindset reasons — which luckily I see is changing. Internal apps/3rd party productivity tools often have loads of users and each one of them is an additional attack vector.

In the case of EFSS products specifically, when the breach happens and the setup was too open in terms of permissions, it’s often too late to do anything — the data is already gone. When a breach is identified, users run like headless chickens removing all links, old accounts, changing their passwords to minimize the damage, but well — that could had been prevented in the first place.

EFSS products offer variety of security features that allow you to secure your data in a very precise way, but only a minority of users take full advantage of all those goodies. There is a bunch of reasons why users don’t want to use security features, and I don’t have yet the power to change how vendors (except of one) build their software, but I can give you a generic tutorial on how to take advantage of what’s available in most of them. You’ll learn what to look for and what are potential consequences and risks of not applying a given security measure.

Just below this paragraph you can find the promised tutorial. If you find it to be a valuable content, it would be great if you forward it to other users in your organization to give them a chance to secure their data. Some of the mentioned items may appear trivial, but reality is that most users fail to do all of these things right. The truth is actually that we very often we fail on those trivial things, because we fall into day-to-day tasks routine.

So here we go:

In terms of general setup:

1. Keep access permissions according to principle of least privilege:

Software often offers per folder/file granular permission settings, which you should use to limit availability of your data to people who actually need it to do their work. Example: your cleaning lady doesn’t need access to executives’ invoices or strategic products roadmaps.

I recommend you to choose the whitelisting approach, which is giving access only to specific individuals/groups as opposed to blacklisting, which is allowing everyone except of specified individuals. New-hires shouldn’t have access to everything by default, they should receive access to given resources only if needed/requested.

2. Secure access to your shared links:

You shouldn’t keep all links open in hope that no one will ever guess the UUID of the link. People share links randomly, use insecure mailing clients, use not secured computers, misclick Ctrl+V and leak links from their clipboard. Sometimes a system generates guessable UUIDs or leak them in the referer header(when you follow the link in the shared document which takes you to different website). It’s wasn’t once that I’ve seen antivirus or browser plugin accessing a shared link on user computer without his knowledge. While it’s done in a good intent, it’s still a privacy concern as you don’t know what 3rd party software does with that link — if it’s sent to their server, how it’s stored and what happens to your corporate data.There are plenty of ways how shared links can leak and no one wants to find one’s invoice archived by internet bots/web crawlers.

While smart vendors protect your links from being guessed by employing various mechanisms like recognizing bruteforce attempts on shared links UUID, there is nothing a vendor can do if users recklessly paste shared links everywhere and don’t configure appropriate access settings.

If the data you’re sharing is sensitive, protect the link with a password or make the link accessible only for logged-in users. If you work with many contractors or want to share content with a crowd of customers, it’s neither recommended nor feasible to create account for each one of them, so go with a password protection. When sharing a file with co-workers — use internal links accessible only to logged and authorized users.

If you use the solution mostly within the company, make internal access to be the default setting for links. Assess what’s the most cost effective approach — take user experience into consideration — for your company and implement it from admin level for all users.

While generating a file/folder link take also a look on access level and other security options you can choose like DRM protection.

3. Set expiry for share links:

Use time/click based expiry for your links. Set expiry on those links which you think won’t be needed after given period of time, so you don’t need to worry about them if a link leaks years later.Don’t allow links to live forever if not necessary and realistically speaking, a significant percentage of the links that are being created are meant to be accessed only a few times.

4. Use strong passwords for your account and shared links:

Modern computer systems have implemented pretty smart solutions for assessing password strength, like popular in web applications and great zxcvbn. If you want to know in details how to create solid passwords, take a look on link under zcxvb, as there is no point in creating one more resource if there are great existing ones.

TL;DR: Use long, unguessable but meaningful (easy to remember for you) passwords.

Don’t require employees to change their complex password too often, because it doesn’t work the way security industry wished it to work. It irritates employees and actually make them set weaker password just to satisfy the system.

5. Enable Two Factor Authentication (2FA):

These days, using 2 factor authentication is so trivial that it’s a shame not to use it. There are still vendors who failed to implement user friendly 2FA, but most have done it well. Whether it’s a mobile application, phone call or SMS used for 2nd step verification — each one if safe enough for regular Internet user.

If you don’t feel comfortable with 2FA settings of the product you’re using and it doesn’t provide a space for customization, then let the vendor know. Security shouldn’t cause a bad experience, because if it is off for you(admin), there are chances it’s also problematic for other people in your company who’re going to hate the product more and more — which leads to lower adoption and irritated users ignore security recommendations.For the common benefit, take the lead and report to the vendor your feeling about weaknesses of their 2FA or any other security feature.

6. Don’t create too many immortal “temporary” accounts:

Do you really need to create an account for that short-term contractor if all he’s going to need is an access to 2 files which you can share with him using a password protected link?

If it happens that you need to create an account for any reason, setup an account expiry for a date when employee’s contract is going to be terminated. The date is usually known at the beginning of a contract so it’s easy to configure and it’s always better to extend account’s lifetime than to forget about blocking it and leaving open access to corporate data.

7. Put access removal on your employee termination checklist:

When employee leaves your company, you should obviously block his accounts on all internal services, but in case of EFSS products the behavior after an account is blocked varies a lot. In some products, when you block an account all links are automatically expired while for another vendor they remain intact, so it’s good if you well understand this behavior in your product.After an employee is terminated it’s a good habit to review links he shared and block those which don’t need to be open anymore.

You may need to leave some links because they have been shared with a current customer, but lots of stuff will turn out to be outdated and unnecessary.“Trust everyone, but cut the cards” is another side to look at this as a motivation for access audits.

8. Reading audit reports:

Most vendors offer great auditing capabilities which is a tremendous help for internal compliance, security and IT team when without any scripting it’s possible to run a report and verify what operations have been done on users’ account and their data. Such audit logs usually includes information like: login history, folders’ permission changes, shared links summaries, user profile changes, info about connected devices and external storage.

Technical admins should on periodic basis review their users’ activity and look for alerts and anomalies. Some vendors provide additional service — usually need to be paid extra — which does automated anomalies detection and it works pretty well, but the human factor shouldn’t be completely removed from the process.

9. Report suspicious activity to tech admin/vendor:

If you react soon enough, you can save your company from suffering from serious data leakage. Immediately report to your security team if you see that: critical data is missing, files/folders get renamed out of the blue, you can’t login to your account or other users behave odd — e.g. download/comment on too many files at once.

It’s always better to report a false positive than miss an opportunity to stop a hacker from stealing your data.

If you’re using a mobile application to access the data, you few more things to do:

1. Setup a solid passlock/password for your application.2. Enable the option to delete all local data and logout you from the account after X failed login attempts — in case your device gets stolen/lost/”borrowed”3. Enable encryption for synced data. It’s usually called a “local/offline data storage encryption”.4. Enable session timeouts so if you leave your phone somewhere it’ll automatically log you out after a set period of time.5. Set “remote wipe” option which allows to remotely clear all application settings. It will terminate active session on your device + initiate erase of locally synchronized data.6. Explore, explore and explore! Mobile apps usually don’t have that many options,so it’s a matter of minutes to get a solid grasp of available functions.

For desktop applications I have only one EFSS specific thing which most users is not aware of because they’re so used to clicking “Next” button during software installation. Some FSS apps ask if you want to allow all users to access synchronized data or make it available only to the user who installed an app. So beware if you share your computer with other people, because if you chose wrong option they’ll be able to access your corporate data.

Except of that you should protect yourself in a way security-aware computer user should: set solid login password, enable screensaver which requires logging in after X minutes of inactivity, enable disk encryption, use AntiVirus software and enable automatic software updates.

When it comes to on-premise appliances a checklist contains a slightly different things:

1. On-prem appliances comes usually with web, SSH and FTP access to ease the configuration process. As soon as you get it out of the box, change the default credentials and set strong passwords for those services.2. After you’re done with configuration, block unnecessary services and ensure you’ve disabled guest access. Nmap will be very helpful here to ensure you did a good job in turning off redundant services.3. Install patches and upgrades as often as feasible. Your corporate data and users credentials are going trough that appliance so you must keep it up to date with latest security patches for underlying OS and a product itself.

This is it. While minor things differ between vendors, this guide should help you significantly improve safety of your data.

* Okay vendors**,** I did quite solid piece of work. It’s your job now to take this draft and describe your products in more detailed way and approachable by regular human being.It would be really useful if each EFSS vendor taken their time and wrote an easy guide into their products’ security functions. I’m sure this effort would be greatly appreciated by users, so sounds like a win-win to me, even marketing-wise if that drives you the most.


Published by HackerNoon on 2017/03/13