This article explains how :Collaborate works to enable seamless data sharing with SSProtect.
Introduction
Today, it's inevitable that data will be disclosed in some sort of unintended manner. It is widely accepted that most companies have been compromised or breached at one point in time. This is not changing in the near future, as criminals have learned how to monetize nearly every piece of information. Add to this geopolitical pressures and the increasing amount of electronic espionage, one might conclude that data is more exposed today than ever before - if even only the result of moving from paper records to electronic form.
Overview
SSProtect protects application data by combining patented cloud-offloaded data encryption with strong access control primitives. Access Control is based on the use of credentials that differ from those quickly compromised by attackers in a breach event. This article describes our approach to managing shared access control to protected content, automatically permitting access among Organization Peers while also providing one-way trust associations to grant permissions to external, Third Party resources.
Non-Intrusive Use as a Priority
We set out to build SSProtect in a way that would reduce motivation to avoid use of protective controls. Since data protection is now a necessary aspect of running any business, and due to the shortage in talent available to help provision, build, and run security departments, we are now faced with an all-time high need for simple data protection capabilities that don't require significant Administrative overhead.
Sharing Permissions vs. Direct Sharing
SSProtect does not move data on your behalf - it protects content at its' source, and you use normal collaboration and sharing tools/ applications to move content to others. Since content is encrypted, recipients must also use SSProtect and have a data sharing relationship with you and/ or your SSProtect Organization before plaintext will be made available (most often using native workflows and In-Place Encryption).
As such, SSProtect only manages access to the managed content. How it gets there, or even if/ when it gets somewhere, is handled independently and by design. This way, leaked data remains inaccessible to unauthorized resources. It also provides the foundation for auditing the use of externally shared content.
Simplified Sharing Permissions
These dynamics motivated our need to build data sharing permissions in a seamless fashion. Traditionally, data encryption products require users to specify to whom a piece of information is destined, either individually or indirectly with group references. Though useful in some situations, it introduces overhead and specifics that inhibit normal end-user efficiency. As such, we have chosen to implement Policy-based permissions managed by those who oversee IT-related services.
This results in data sharing permission management that supports normal end-user workflows without sacrificing security. Those in need of more granular control can use the software with third-party solutions that provide more complex capabilities. As for usage tracking, you can also use additional software though SSProtect in many ways transcends the capabilities offered by others. Though important, it is outside the scope of this article. More information is available in the :Assess Section.
IMPORTANT: Content must be moved by systems or Users independent from SSProtect. :Collaborate manages access to content, but does not move or copy content, and does not make it available for others (except when using disaster recovery services like :xRecovery, for example).
Organization Sharing Permissions
SSProtect Organization access permissions are straightforward: Every SSProtect User in a single Organization has permission to access content created by any other User in the same Organization. Scope is determined by the set of Users deployed by a single Administrator and his/ her Delegates. The list of Organization Users is available in the Administer Users display.
Third Party Trust Data Sharing
To grant, "external" permission to protected content, use Third Party Trusts from the Data Sharing display. This process works as follows:
- An Administrator authorizes access to a specific User in another Organization
- The authorized User can access content created by any User in the granting Organization
- Content must be independently delivered to external Users: SSProtect does not expose content
- The Administrator's Organization cannot access the external User's content
- The Administrator's Organization Users maintain access to content received, "back" from those authorized to make changes
For example, consider Company A with Alice and Alan, then Company B with Bob and Betty. Administrators and Delegates are only relevant to the extent that they can configure external (Third Party Trust) sharing relationships.
If Bob wants to share a Word document with Alice, he can ask a Privileged User in his Organization to authorize the Third Party Trust (described here). Once complete, Bob can send the document to Alice using email, a thumb drive, or Dropbox. The file is protected, so it cannot be opened by malicious actors that intercept its' content.
When Alice receives the file, she accesses it just like any other file - though she must have her SSProtect credentials (and optional 2nd factor authentication token). She opens the file, makes several changes, and returns it to Bob using email, a thumb drive, Dropbox etc. Bob can then open the modified file.
Betty, being an Organization Peer to Bob, can access content as well - even the modified version Bob receives back. She first has to acquire physical access to the file, and of course all access is audited. But because she and Bob are in the same Organization, she can access content Bob, "owns". By nature of first adding SSProtect protections to a file, Bob becomes that owner.
Perhaps more importantly, Alan does not have access to any of the noted content - if he were to intercept communications and steal the file, at any point along the way, he wouldn't be able to get to plaintext content since SSProtect manages sharing permissions and thus key distribution. Though a more advanced topic, he also wouldn't be able to break into Alice's host computer and acquire the encrypted file or find decryption keys - they simply aren't there, by design.
Second Degree Permissions
Continuing with our previous example, Alan, though an SSProtect User in Organization A, cannot access the document (as noted). Alice is able to give the original document - and the one she modified - to anyone, but they will not be able to access it unless a member of, or specifically authorized by, Organization B. This, "2nd level" transitive sharing relationship is prohibited. For such a transaction to take place, Organization B would have to configure Alan as a Third Party Trust (since Bob is the "owner").
One Way Association
Further along in our example, let's say Alice creates a file, protects it with SSProtect, then shares it with Bob (email, Dropbox, etc). In our scenario, Bob won't be able to access her file's plaintext content - the noted Third Party Trust association between Company B and Company A is one-way.
As a result, Alice would have to speak with a Privileged User in her Organization (A) to authorize Bob as a Third Party Trust to her Organization A.
Also note that timing is secondary: Alice can protect and send the managed file to Bob before any Third Party Trust has been configured. Though Bob would not at first be able to access plaintext content, that would change after an appropriate Third Party Trust relationship was established.
With SSProtect, the location of a document matters little - the real-time Access Control permissions managed by Third Party Trust collaboration (and Organization Peer permissions) governs access. This decouples storage liabilities with access control, which can be an important risk mitigation for those subject to regulatory requirements for long-term document storage.
:Email vs. Email
In this this scenario, we discussed the idea of Bob sending the document to Alice using email. This is perfectly normal - Bob can protect the file then send Alice an email with the protected attachment. This is quite different than using :Email, however, since it allows you to further protect the message's content.
Both cases are acceptable, though it's worth noting that :Email includes and enforces Policies specific to the way attachments are handled, i.e. you can configure it to automatically protect plaintext attachments, refuse delivery of unprotected attachments, and even restrict use of delivered, protected email content. For more information, refer to the :Email Category of articles.
Getting Data To Other Users
As noted, you can share protected information with your Organization peers using any mechanism you normally use for unprotected content - except now you maintain protection the entire time. Use email, network drives, thumb drives, Dropbox or other sync and sharing solutions, FTP, Secure Shell - it makes no difference at all how the information is moved - it remains a protected file.
The only stipulation for access is, of course, that the recipient use SSProtect with a valid Account in your Organization or instead be configured as a Third Party Trust.
Benefit of Controlling Shadow IT
SSProtect has tremendous benefit to companies where shadow IT deployments of sync and sharing solutions have been deployed against company policy. This happens all the time, and SSProtect offers a way to help control information without limiting individual groups from using their preferred solution.
If IT were able to deploy SSProtect across 3 business units, for example, all using different sync and sharing clients (Dropbox, Box, and Egnyte for example), SSProtect would sit, "underneath" and protect information as it flows through these systems. However, IT would retain visibility of these transactions with :Assess, seeing all data open/close events and the associated IP addresses (with other usage information, such as managing application). This provides visibility into where company data is being shared - and how and by whom - which is quite useful in trying to maintain control over sensitive data. When under the protective scope of SSProtect, of course if IT handles administration, then someone on the team would have the ability to disable accounts and/or limit access in the situation where policies are ignored or violated. None of this precludes use of any sync and sharing solution, and most of it is to the benefit of the corporation.
Effects of Account Changes
Changes to Account configuration are immediate, except any materials being accessed at the time of the change obviously remain accessible until the file is closed. This allows Organization Administrators and Delegates to revoke access and ensure no further data sharing takes place.
New Third Party Trust relationships generate notification email to authorized Users, which must then with SSProtect perform Refresh Login to pick up changes (this actually exchanges permissive keys that govern ongoing Policy). This step is of course not so immediate, but subsequent Administrative adjustments go into effect immediately.
Combining with :Recover
:Recover provides a mechanism for seamlessly storing protected content in the cloud for recall at a later time. :Recover in fact can provide individual version recovery, allowing you to see the state of a file as it existed for every open and close operation, by any authorized user, on any machine or network*. Of course, storage is limited by Organization Quota that Privileged Users distribute to Accounts (users) any way they see fit.
When combining :Recover with :Collaborate, malicious attempts to sabotage information are easily kept in check. If, for example, an employee is terminated and he/she tries to delete information in sensitive documents, it is of minimal consequence when using :Recover - pre-existing versions can be read, but not deleted.* Even if the terminated employee deletes all files from his/ her host then throws his/her laptop into the ocean, your SSProtect Privileged Users can recall protected content after these sabotage events occur.
* :Recover uses a concept we call Retention Policy, which can limit the number of stored versions for each managed item. Retention Policy is designed to maximize the use of storage Quota, but it is optional and not used by default. For more information, refer to the article, Archives, Quotas, and Retention Policy).
Re-Protection Policies
When a sharing peer re-protects a managed file, SSProtect maintains the conversion policies set forth by the owner/ creator when the shared instance was created. :Recover Archive materials are also associated with the creator/ owner.
If for some reason the creator/ owner is at his/ her Quota limit, re-protection will fallback to Optimized Offloading, maintaining protections but not storing content. For more information, refer to the article, Operating Modes.
:Recover Content Accessibility for Third Party Trust Content
:Recover Archive content does not, by default, provide Restore access to Third Party Trust instances. These individual versions of managed content are enumerated in the Managed Files Versionlist display, but cannot be Restored unless you are using Double Conversion (which must be explicitly enabled by Support upon receipt of an authorized change request) -OR- content was accessed by an Organization Peer.
:xRecovery offline archives work a little differently: Third Party Trust instances are never available, no matter whether you are using Hybrid or Double Conversion whereas Organization Peer instances are always present (when scoped by the request).
For example:
- You create a file, protect it, and share it with a Third Party Trust (creating version 1)
- The Third Party Trust opens and changes content, then saves and closes (creating version 2)
There are now two versions of the file you own: v1 holding your original data and v2 holding modified data. If you were using Hybrid Conversion when you protected v1 of the original file, there is no way for you to access v2 content except by directly receiving the modified file and opening it. When you close that instance, you create v3 which contains v2 edits (and any changes you subsequently made to them).
When using Double Conversion, you can access this Third Party Content (from the UI), and thus Restore the v2 instance.
When using Hybrid Conversion, if the Third Party Trust was instead an Organization Peer, you would be able to access and Restore v2 content (since your peer utilizes the same Organization sharing materials).
For more information, refer to the :Recover and :xRecovery information topics.
Additional Resources
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to support@definisec.com, and our staff will respond to your needs as soon as possible.
In the meantime, don't forget to check out our primary website and Insights columns for information on current trends, security topics, and how our technologies relate.
This article was updated w/ v9.7.2 of the :Foundation Client