BlogKnowledge we want to share

21.11.2018

Where are you headed, EFSS? Insights at the end of 2018

Where are you headed, EFSS? Insights at the end of 2018

Enterprise File Sync and ShareWhy would anyone want to have it?

Difficult topics presented in an understandable way – Q&A with Paweł Staniec*

Today I would like to ask you about File Sharing. Especially in corporate and enterprise environments.

Sure. I would start by asking a question: Why would anyone want to share files nowadays? On a daily basis, we certainly do not notice how many corporate processes related to communication and working with data are strictly related to this issue. ‘Instant’ is the keyword here. This, of course, easily leads to time savings and intelligent work with files and content. Unfortunately, in this rush, we often forget about the element that should be crucial – security. One day I have asked my network on LinkedIn: If you need to send a file that weighs 300 MB to your business partner or colleague, how would you deal with it? I have added that I am looking for a solution that has two qualities – simplicity and security. There were some random answers about using the GPG*, splitting and sending via email… No one came up with an answer saying: “This tool does it.” This made me realize that a lot of us are still struggling with what solution to use when we need to move data from one computer to another. Some said to use one of the public cloud providers, but no one could explain what would happen with their encrypted data. These are all non-trivial aspects of the file-sharing world today.

*GnuPG is hybrid-encryption software that allows users to sign their data and communications.

Ok, so is Enterprise File Sync and Share the answer to these challenges? Is that why should all enterprises want to have it?

I think I would ask this question in a different way: Why would anyone not want to have a solution that facilitates work, increases efficiency, guarantees control over data access and security, and generates savings? EFSS is not always the perfect solution, but I think it is as close as it gets for most clients.

PM: How are EFSS tools different from public file sync/cloud services? Why not WeTransfer, Dropbox, Google Drive…

Certainly, they are tools of well-known brands, supported by companies that have operated in the IT market for a long time. All these solutions have a number of advantages, but also one major disadvantage. For the user, despite all assurances from the solution providers, it is not entirely clear whether these data are definitely secure. In particular, are they encrypted or visible to other people? And above all, where are they stored? It is also worth remembering that before any data gets into your secure storage, it has to leave your company premises and travel a long way through the network to get there. This poses another potential risk for sensitive data.

This is one of the primary goals for KODO. We give users the freedom of choice. It is the client who decides about every aspect mentioned because KODO can work inside a company’s infrastructure, under full control and supervision of the information security department or your own IT department. We allow you to configure advanced policies in relation to data retention and control of specific file versions. As the infrastructure owner, the client also has full control over where the data land, and who and how can access them. If you do not need that level of control, you can still use KODO as a SaaS.

Let’s go back for a moment to data storage. How can I be sure that the data sent to KODO is safe?

A very good question! You can have the best backup of file sync service, but if you store data using an unreliable storage… it is worth little to nothing. In case of KODO, data lands in the IBM Spectrum Protect system. We have chosen it for storage backend as this is one of the best solutions in its class when it comes to file storage, data security, deduplication (reduction of the number of copies of the same file), and encryption. This is a solution that is the result of many years of IBM’s experience. All of the on-prem installation data is located in the client’s infrastructure. IBM Spectrum Protect, previously called TSM – Tivoli Storage Manager, is a separate server, a mechanism for securing data.

Of course, one can say that it is an overkill for their needs. We are carefully listening to all the feedback our users provide us with, and I think I can reveal the fact that we are working on a new version of KODO where we will be able to store the data initially in the filesystem and then in other data storage mechanisms.

But if someone already has IBM Spectrum Protect, why would they need KODO?

KODO is needed because Spectrum Protect does not support the endpoint-centric approach natively. It does not provide an administration panel and a module for user management, nor interfaces that would allow end users to upload and extract data in an easy way. Spectrum Protect is a mainly administrative tool intended for professionals in the field of data security who know how to configure file or application servers in such a way that they transfer data to Spectrum Protect – it is efficient and effective, but it is not nice, convenient or flexible for the end user. The client-side agent does not even have a graphical interface (it offers a command line instead) and requires a bit of tech knowledge to configure it.

Sounds good. Is there anything else that is better in KODO than in the competing EFSS products?

This is a really tough question as KODO is unique in a way – it combines Continuous Data Protection (backup) and EFSS features. I think one of the main pros that we already spoke about is that it can be installed as part of the infrastructure owned by the client. It can be configured within their infrastructure, be it physical, virtual or bought as a service (for example a cloud service similar to Dropbox or OneDrive). Our main competition has mostly switched to offering cloud models exclusively. Another thing is that EFSS combined with the feature scope offered by KODO is a simple way to achieve elimination of attachments, centralization, and security of data storage, as well as access and authorization management.

Ah, data centralization… Is Office 365 backup a step forward on the road to centralizing and protecting all company’s data?

Spot on! We have introduced this feature mainly to protect companies against the unavailability of Microsoft’s infrastructure – it is necessary to have copies of data on one’s own servers. It is also a good solution to protect oneself against unintentional or deliberate deletion of data by the employees (yes, this happens quite often). It is known that there are many more causes of the so-called disaster, but the most common ones are related to human errors. It also has to do with the erroneous belief that if we have data in the cloud, they are safe. And yet the data is our property and it is our duty to protect it. Another thing that KODO Office 365 backup can be used for is preparing a migration of data to another provider (e.g. from Microsoft to the Google cloud). KODO allows you to download it to an on-premise system and restore it in a target cloud – be it Google, BOX or a client’s physical infrastructure in the future (e.g. Exchange or local file shares), should a company decide to leave Office 365, for instance, because of costs.

It seems that you are not putting a lot of trust in Cloud Services?

No, not at all! I mean, we need to realize one basic thing – cloud solutions that are definitely going towards a multi-cloud strategy are the future for business. The faster companies build infrastructure that allows them to efficiently use the available technological resources, the faster they can gain a competitive advantage in the market and less work will be required in the future. And this work is inevitable, though we may not yet realize it. What we totally realize, however, is that cloud and especially multi-cloud strategy helps you to:

  • reduce the risk of vendor lock-in;
  • reduce the risk of going full-out in case of cloud outage;
  • avoid unpleasant situations related to the regulation of service providers in specific countries;
  • optimize access time associated with geolocation to improve performance;
  • start the journey towards flexibility boost, agile innovation development, and rapid deployment.

But it is critical to realize one thing: even despite the fact that data can be distributed to multi-cloud environment, you still have to be ready for the worst-case scenario. You are still responsible for having a backup and guaranteeing that your users have access to critical information even if your cloud provider’s Data Center burns down. Your cloud provider will not reimburse lost contracts, lost leads, or lost reputation.

Thanks, I think that’s it for now, and maybe next time we could talk a little bit more about some real-life use cases for the KODO EFSS?

Thanks, that would be great. I have some amazing client success stories and they come with some interesting lessons that are worth sharing!