SSProtect protects application data by combining patented cloud-offloaded data encryption with strong access control primitives independent of the type of credentials quickly compromised by attackers. This article describes our approach to secured seamless data sharing that uses automatic shared Organization access and one-way trust relationships for third parties, each designed to simplify the process of protecting and working with sensitive data without adding to the risks of unauthorized data disclosure.
The Reality of the Need
Today, the probability of having data disclosed in a breach is close to 100% given only the short period of a few years. It is believed that over 90% of all companies have been breached. This number is not falling, it's rising, as criminals have learned how to monetize nearly every piece of information. Add to this geopolitical pressures and the increasing amount of electronic espionage, and it's clear data is as exposed today as it has ever been.
Non-Intrusive Use as a Priority
We set out to build SSProtect in a way that minimizes the impact of security to the extent that inconvenience would no longer justify inaction. Since this is now a much more necessary aspect of running a business - in fact now required - and due to the shortage in talent available to help provision, build, and run security departments, the need for high levels of protection without workflow intrusion and significant Administrative overhead is at an all-time high.
This motivated the need for us to build-in seamless data sharing. Many encryption products require users to specify for whom a piece of information is destined, or to what group access should be permitted. This is useful in many situations, though in others it is overhead that inhibits normal efficiency. In other respects it's inappropriate - end-users shouldn't be forced to deal with the concept of data sharing policy each time they access sensitive content. This is best left in the hands of policy makers.
We thus chose to offer sharing in a specific way that permits normal workflows without sacrificing security. Those that need more granular control can use the software with third-party solutions that provide more complex data sharing relationships. The same goes for tracking, though SSProtect in many ways has a great deal of visibility not achievable with traditional designs. This latter point is significant, but outside the scope of this article. More information is available in the :Assess Topic.
Organization Data Sharing
SSProtect Data sharing is straightforward: Every user in a single Organization can access information created by any other user in the same Organization - all of the time. If your Account is operational and not restricted by Administrator actions, you can access any SSProtect'd file or email message sourced by another member of the same Organization. Organization scope is determined by the set of users deployed by a single Administrator and his/her Delegates. The list of Organization Users is given in the Administer Users display. The list of Third Party Trusts specifically given the same level of access can be found in the Sharing Policy display (see next section). Both displays are available from the notification icon's menu, though Administer Users is limited to Privileged Organization Accounts.
Third Party Trust Data Sharing
We recognize the need to share data outside of an Organization, though this requires a bit more control and cannot be automated. We chose to keep it simple, opting for integration with specific solutions for more granular control. As such, Third Party Trusts work as follows:
- An Administrator authorizes sharing to a specific user in another Organization
- The authorized user has access to all of the Administrator's Organization content
- Content must, of course, be given to the external user before he/she can access it
- The Administrator's Organization cannot access the external user's content
- The Administrator's Organization Users maintain access to Third Party 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 normal email, a thumb drive, or even 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. Bob opens the file, decides he likes the work, and sends it to Betty. Betty can with her SSProtect credentials access the file as well - because she and Bob are in the same Organization.
Second Level Sharing
What if Alice works in a company with people that have questionable ethics? Let's say Alan in IT is one of those people, and he decides he wants to look at the file Alice received from Bob. Even though he's an SSProtect User in Organization A, he cannot access the document. 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 as well.
One Way Association
Let's say the next day Alice comes in and decides to share with Bob a file she was working on several days ago - a file she protected with SSProtect . She sends this to Bob, but he can't open it - Alice would have to speak with a Privileged User in her Organization to authorize Bob as a Third Party Trust to her Organization A.
It's worth noting, in this case, that Alice could share the file with Bob before the Trust Relationship was established - though Bob would not be able to access content at first, once the authorized Trust was configured, he would then be able to proceed.
As such, access to plaintext content is decoupled from location or logical access, and is governed by SSProtect Trust Relationships (inherited via Organization membership or specifically authorized as a Third Party Trust).
: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 Topic.
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 is, of course, that the recipient have a valid account in your Organization or be authorized as a Third Party Trust in order to make use of the protected content.
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 insure no further data sharing takes place. Also note that empowering Third Party Trusts requires the newly authorized user to Logout and Login in order to update keys - this step is of course not so immediate, as a result, though does come with email notification for the recipient (that includes directions to that effect).
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 is by default limited to retaining the latest 3 versions of each stored file, removing older instances to make room for new items. Organizations can increase this number - or request that files never get removed to make more space (with an impact to Quota flexibility). This has an impact on the type of information that remains available over time.
For more information, refer to the :Recover Topic.
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.
IMPORTANT: :Recover Archive content, created by a sharing peer, cannot today be Restored, and is also not available in an :xRecovery Offline Archive. However, once changes are returned to the owner/ creator and consumed, the re-protected instance will carry edits (and any changes made to them). This is due to the complete isolation offered by Hybrid Conversion. Future versions will permit sharing peers to Restore version instances they create.
For more information, refer to the :Recover and :xRecovery information topics.