This article introduces you to basic use (and some advantages) of SSProtect for secure data management.
Introduction
SSProtect combines data management and security using patented service components integrated into a full-featured cryptosystem. Technologies and innovations were specifically developed to combine strong security, high availability, and auditing certainty compatible with existing infrastructure and application investments. The resulting solution is both easy to administer and use, and helps you and your Organization maintain operational continuity through today's most challenging data security dynamics.
Refer to our @DefiniSec Insights articles for ongoing development and applications, and/ or send specific inquiries to our Support team and we will provide directed insight to help you address your specific needs.
The remainder of this article shows you how to begin using the software after you have provisioned an Account. For guidance, refer to the Getting Started set of articles.
General Operation
To use SSProtect with application data, or, "unstructured content" such as Office and/ or PDF documents (most will be compatible), you must first tell the software which items to protect. This can be automated with a variety of tools and technologies, though this article describes manual operation.
Managing Files in Explorer
When browsing your host computer's stored files with Windows Explorer, you can right-click one or more (up to 15) files then choose SSProtect Activate to apply SSProtect security and management to sensitive content.
This process - like all others - generally requires a two-factor authentication credential which can be delivered using a touch-sensitive USB token. 2FA is however disabled when you start, and as such you will only need to provide Login credentials once, and for the next hour will be able to utilize the resulting Session (at which point you will be prompted to re-enter your password, though only if you initiate managed activity).
Once you Activate Protection, the target files are encrypted* and a small red overlay icon will appear on the file's original Explorer icon. This indicates that content is being managed, and will as a result require the use of SSProtect and proper authorization to access content.
* SSProtect manages your data with a combination of Encryption, Integrity Protection, Access Control, Versioned Backup (optional), managed Policy, and cryptographic offloading further described below.
Removing Managed Oversight
To reverse this process and remove items from protected management, in Explorer hold the shift key then right-click the protected file(s) and choose SSProtect Release. This will unprotect and decrypt content to unmanaged plaintext you can then use independently.
NOTE: Depending on your User Context, Account settings, and the target file owner's permissions, you are not always authorized to Release Protections.
Fifteen Birds, One Stone
Activate and Release both work with up to 15 files. To perform operations on folders and sub-content, use the Bulk Conversion UI available from the SSProtect notification icon's context menu. For more information, refer to the article, Bulk Conversion.
Cryptographic Offloading
SSProtect utilizes cryptographic offloading to move sensitive operations into highly secured and managed environments. This protects sensitive operations from potential threats that may have access to your resources while executing critical operations from a central point of visibility. This provides fine-grained host audit records that are exceedingly difficult for attackers to modify.
For information on :Assess, the fundamental Reporting component available with all SSProtect installations, see Acquiring Data Access Reports.
Explorer Mode Limitations
You can apply protections to most any file-based target, with exceptions noted below:
- OS encrypted files (arbitrary policy, different from Bitlocker'd volumes)
- Read-only files (honoring user intent/ policy)
- Offline files (that are not available while disconnected)
- Reparse points
- Sparse files
- System files (arbitrary policy)
- Device files (though removable storage remains compatible)
In most cases, your target files will qualify - most exceptions are advanced cases or simple policy decisions that can be changed (as is the case with OS-encrypted files, different from those afforded encryption using Bitlocker). Note that the Device limitation does not mean you cannot protect files on a removable thumb drive - this is in fact a quite-common use case.
In-Place Encryption
In-Place Encryption is a unique capability that builds on standard file encryption considerations to provide continuous protection to data while you work with it in native plaintext form and application containers. This blocks attackers from waiting for you to open protected content before quietly offloading plaintext files/ content in the background - a common approach that is most often highly effective.
To utilize a managed file, double-click the file from Explorer to open it. This launches the registered application (based on the file's extension) at which point SSProtect intercepts the request and carries out authentication and authorization using cloud cryptographic services. Once you've provided a 2FA credential by tapping a USB key (when required), for example, plaintext content is then loaded by the application for you to work with - natively and with minimal delay: The Application has no knowledge that content is being restricted by the filesystem (not to be confused with On-The-Fly-Encryption, which exposes memory-resident crypto keys). This blocks all other processes from accessing interim stored plaintext content used by your software.
Of course, when you are finished editing/ reviewing content, SSProtect detects this transition and reverses the process, maintaining control over the managed content until it is completely reprotected. Only when finished does the software release the protected content for forward system use, which means it can then be renamed, moved, and shared with others.
During this process, re-encryption keys are not present on the host computer - and thus not locally available to attackers. This provides complete, continuous, application-independent protection while allowing you to work with managed content in native form.
Login Gates and Fine-Grained 2FA
In a common scenario, attackers penetrate host computers then wait for an end-user to Login to a protective system before slowly and quietly stealing unlocked content. For a lot of protective systems, this is an effective approach to bypassing controls.
SSProtect's patented mechanism builds fine-grained 2FA directly into the data access transaction, offloading sensitive operations to KODiAC Cloud Services. Because 2FA often requires a physical presence that is nearly impossible for host-local attackers to assert, common impersonation attacks fail - and access to managed materials remains directly coupled to your actions.
When taken together with In-Place Encryption and application-independent isolation, attackers must resort to more advanced tactics that are, "loud" from the standpoint of additional host protections (anti-virus/ malware). Together, they greatly increase the protective posture of your system (while also maintaining fine-grained, secured access auditing information - see below).
Experience Continuous Protection
If you want to experience In-Place Encryption first hand, open a protected file - either by double-clicking the target in Explorer or from a File Open menu sequence inside the default application handler for a managed item's file extension.
Once opened, use Explorer and navigate to the file's location. Notice the red overlay icon, used to indicate that a file is protected (and owned), no longer exists for the opened item. This is because the file is in plaintext form, though it can only be accessed by the associated application instance you've used.
To see this in action, while opened, from File Explorer try to rename, copy, or even open the file with another piece of software: You cannot. Managed content is "opened exclusively" for the management application you're using, and as such it is the only host process permitted read/ write access to stored data. This is enforced at the filesystem level, which precludes a simple yet effective offloading tactic used by nation-state attackers.
Now Save your changes then Close the managing application (or document instance). Once the red overlay icon re-appears in Explorer, you will once again be able to copy, rename, move, and even open the file with other applications (to view the resulting ciphertext).
You can in fact use this procedure with content placed in Sync and Sharing folders without concern that plaintext content will be sync'd to the cloud. Try it with your favorite EFSS software - and let us know if we're wrong: We haven't encountered a sync and sharing solution that works in a way that circumvents these facilities.
Experience Application Independent Protection
You can observe application independence using Acrobat DC to convert a protected Word document using its' Explorer context menu. Try this with a protected .docx file and notice you are prompted for credentials (2FA or Login Password, if/ when required - or none at all) before the red Explorer overlay icon disappears. That happens just before the PDF is created, at which point the red overlay icon is re-presented, indicating that content is re-encrypted (it remains protected as noted above).
Note that the resulting PDF is in plaintext. Remember that the software is managing the .docx file, not any file created by an authorized application utilizing In-Place Encryption to manipulate content in a secure fashion. For more information, contact our Support team.
Critical Visibility and Incident Response; SSProtect :Respond
Though In-Place Encryption offers continuous data protection w/ granular 2-factor authentication, and though this makes it far more difficult for adversaries to engage in mass exfiltration of sensitive data (when under the protective scope of SSProtect), the more distinctive value comes from additional innovation:
- Cryptographic offloading utilizes keys from the host and also the cloud
- Keys are independently generated and only combined w/ proper authorization
- Authorization comes in the form of 2FA, carried out in the cloud
- The resulting central control point holds priceless control/ insight on reality
Cryptographic offloading works by splitting keys between the host environment you work in, and the offloaded, secured environment managed by the ISP (DefiniSec as a cloud service provider). Because keys are regenerated each time content is closed, and because keys are never in the same place at the same time except after authorization due to 2FA verified in the cloud, the result is a great deal of control and insight into where, when, how, by whom, with what application, on what host, and for how long managed content was accessed.
The disclosure risk insight available from historical event auditing analysis, and resulting Disclosure Risk Reports, are more fully described in the article, :Respond Introduction.
In-Place Encryption Limitations
Though In-Place Encryption is by nature application-independent, there are exceptions. Some are as a result of Explorer's desire to try and interpret files on your behalf - like .zip archives. These will not operate with the In-Place Encryption workflow - you have to manually release protections (shift-right-click, SSProtect Release in Explorer), work with content, and manually re-protect (right-click, SSProtect Activate). The software will attempt to maintain the version and file ID chain (for reporting/ tracking), though in some cases the chain is interrupted and a new instance of the file is created (with a new ID and new progression of Version information).
You may notice that File/ Open from within Notepad (against protected .txt files) does not work. This was not the case when the software was originally developed, and the circumstances leading to this incompatibility are well-known. We anticipate a fix for this in upcoming releases, though at present you can still double-click a .txt file from within Explorer, noting that the continuous protections from In-Place Encryption remain valid.
There are similar situations where software proxies document instantiation using third-party libraries. The correlation isn't direct or obvious, and also may be subject to dynamic changes based on other installed components. We can work through many of these situations if you share details with our Support staff.
For example, with PuTTY, a common terminal application used to access remote host computers with sensitive SSH keys, protections aren't automatically aligned simply because putty isn't automatically registered as the default application for the .ppk file type. This is described in the next section.
Make sure to let us know if you encounter issues, and we'll work with you to come up with a solution.
Default Registered Applications, For Now
In-Place Encryption relies on the association created when registering a default application for a given file type (depicted by its' file extension). Our team is working on extensions to this mechanism that will allow you to associate more than one application to existing file types, for example OpenOffice for Microsoft Office files, Notepad++ for .txt files, and so on. We anticipate that these capabilities will co-exist, and the goal is to provide suitable defaults so you won't have to configure capabilities independently.
Note however that the mechanism is truly application-independent; this is only the trigger used to determine when to interrupt normal proceedings. Try to protect a data file manipulated by your own custom software - so long as you create a file type and associate your custom application as the default used to open that file type, SSProtect should be able to apply In-Place Encryption for you, out of the box.
Because the filetype association is configurable within Windows, you can affect behavior even with the single application association Windows provides. Take for example an SSH key in a .ppk file you want to use with PuTTY (a popular terminal app w/ telnet, SSH, rlogin, etc). PuTTY isn't by default registered as the handler for .ppk files, but you can make the configuration change then open a PuTTY profile and engage a connection using SSProtect'd .ppk targets - and when you do, SSProtect will intercept and convert the file for secure access to the plaintext keys then allow PuTTY to operate normally - while maintaining exclusive isolation of the SSH keys.
Remember, though, that this is presently a single-session operation, meaning another instance of PuTTY won't be able to read the resulting protected plaintext for another session using the same .ppk file. This is another extension our team is reviewing, and because it's helpful in some cases and not in others, the results will likely be flexible and configurable. In the interim, you can make multiple copies of the same file, in protected form, and instantiate independent sessions with each.
Seeing - And Feeling
You can see this and other related In-Place Encryption examples in our 3-minute Videos. If you don't yet have the software but would like to try it for yourself, the first video will show you how, in 74 seconds, you can download, install, and protect Outlook Email using SSProtect and the :Email component available as a fully-functional trial download.
Re-Encryption and Default Protected Workflows
SSProtect was designed to offer and by default retain protected workflows for your content. End-users can, by default, Release protections when authorized. As an Administrator or Delegate, you have the ability to deny such permissions to Organization Accounts (Users) as you see fit.
Note that this does not preclude Save As operations, which place plaintext in an unprotected file. At the time of this writing, SSProtect does not track such dynamics though may in the future. Continue to the next section for related considerations.
End-User, Task-based Policy Controls
We are well aware of the many use cases that require policy-based limitations on certain actions, such as printing, print screen, copying, pasting, Save As, etc. And though we are constantly reviewing our approach and feature set, these capabilities are perhaps better suited for rights-management solutions SSProtect was designed to enhance, residing, "underneath", specifically providing protection from challenging threat dynamics. We believe that by retaining strong focus, we are better positioned to succeed. As such, right now, we defer to others directly and specifically focused in these areas such that we maintain the effectiveness of our data protection and Incident Response capabilities while they deliver print and end-user rights management capabilities.
Application Behavior
In some cases, you may use a non-default software application to access a protected file - or perhaps you do so on a host without SSProtect or with the software shutdown. In these cases, the target application interprets ciphertext, which is of course meaningless.
Every application responds to improperly formatted files in a different way. Office for example will give you an option to try and recover a file, while other applications note that a file is damaged if the data it reads doesn't match what's expected. Still others say the file is of an invalid type. Any failed attempt to natively access protected content - whether double-clicking in Explorer or through an application's File Open menu - triggers the application's automatic response. Though at first this may be confusing, it becomes second-nature after a little bit of practice.
Closing and Re-Opening Protected Files in an Application Container
In limited cases, a file may not be immediately re-protected when you close it from within managing software (vs. closing the containing software instance). In such cases, protections remain intact and plaintext access remains in isolation until the application terminates, at which point the file will be re-protected.
In still other (somewhat limited) cases, item re-protection may be slightly delayed after terminating an Application hosting protected content. In such cases, it may be that the Applications removes visible components but continues to perform cleanup that lasts for many seconds longer. For these cases, when SSProtect relies on termination, re-protection is as a result equally delayed. Though at first this may be somewhat offsetting, experience has taught us that such nuances quickly adjust our expectations, most often (but not always) presenting very little trouble.
In each noted case, content retains exclusive protection and is not exposed during these delays. To avoid confusion, when first starting to use the software, it's best to limit application use to a single protective item at a time and expand use cases slowly to familiarize yourself with operation and nuances.
Icon Overlays
SSProtect uses a small icon overlay in Explorer to depict the state of protected files. There are three states:
- No Overlay - Unmanaged file or opened in a managed/ protected context
- Red - Managed, "owned" by the active Profile, and accessible
- Yellow - Managed file, potentially accessible, likely shared content (not immediately known)
In general, a Yellow icon overlay indicates access uncertainty, resulting from protections against Information Disclosure. If for example you copy a protected file that is shown with a Red Overlay icon, and create a new instance in the same folder, the new instance carries a Yellow overlay icon until you open/ close it.
As such, if you move or rename a file (or sometimes when you delete a file then undo the delete), the overlay will transition to Yellow. If you receive a file from an outside source and save it to disk, it too will be Yellow. Once you open and close it, it may transition to Red - but only if you're recognized as the Owner (for example after a rename, move, or copy operation).
Though in written form this may sound confusing, in practice use has been determined to be fairly straightforward and easy to understand.
Third Party Trust Icon Overlay Status
If you access protected content with secure open/ close (In-Place Encryption), and the content is from an external Organization that has granted Third Party Trust permissions to you, the overlay icon will remain Yellow even after you open/ modify/ save/ close. This is purposed, reminding you that content is managed by others. It is also an indicator that you cannot share content with those your Account trusts and expect them to have access, since sharing permissions are not transitive.
For more information, see the article, Protected Data Sharing for details.
In Closing...
SSProtect offers a tremendous amount of capability, all aimed toward making certain sensitive data retains protection from unauthorized disclosure while at the same time minimizing its' impact to your daily use. Though this article points out numerous exceptions that may lead to some initial confusion, we have learned that the impact is fairly easy to manage and far exceeds the, "traditional" methods of file encryption - which cannot provide the type of continuous protection that is no longer optional (not to mention the integrated value of additional SSProtect components).
Though data breaches are impossible to prevent all the time, SSProtect is remarkably effective at minimizing the type of mass data exfiltration common with nation-state attackers and espionage dynamics while at the same time providing tools for Security teams to greatly increase Incident Response and Recovery activities. This is all implemented in a fashion that helps minimize disruptions resulting from sabotage, data loss, and even internal malice.
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.1.3 of the :Foundation Client