SSProtect manages host-based information using encryption, integrity protection, strong access control, and a variety of additional protective facilities such as native workflow integration and continuous protection while data is used in application software.
With the optional use of :Recover, information is securely stored in an isolated Archive (often in the cloud) for restoration at a later time. The process was designed to be minimally intrusive with respect to end-user workflows, with results that are truly seamless except for a change in the way data is sent to and received from KODiAC (Cloud) Services.
Data transfers and storage are governed by a combination of proprietary secure networking primitives, patented cryptographic offloading, and isolation. This tight coupling manifests in several different Conversion facilities, each with different features, as detailed in the article, Operating Modes.
The Managed Files/ Restore context menu selection (from the SSProtect notification icon) displays the set of managed data files associated with your SSProtect Profile, described in the article, Managing Host Data.
From the Hostlist display, choose a managed item (with a Protected State) then choose Versions... to display the Versionlist:
The Versionlist shows each individual managed instance of the chosen file, with each instance representing a secure access operation carried out by the noted SSProtect User(name). It also provides an indication of what's available for recall when :Recover is enabled.
Versionlist - :Recover and Size
In the example above, Version 4 shows a Size=0. This does not reflect the size of the file in host-local storage, rather the size of the Item stored in the :Recover KODiAC Archive. As a result, Version 4 is not available for Restore - as further evidenced by the, "-" in the right-most Archive column.
This scenario can result from failed Hybrid or Double Conversion that falls back to Optimized Offloading, perhaps due to Quota restrictions. This can also be a direct result of a Mode change to the owning Account (since sharing peers do not influence the Conversion mode applied to the file, its' owner's settings dictate the method).
Details are included in the Host Debug log and File Auditing details available in various Reports to authorized Users.
Verisonlist - :Recover Availability
There are other cases where content stored in the KODiAC Archive is not immediately available for Restore, such as with Version 3 of the above example. Though the Versionlist display doesn't provide insight on why an item isn't available, in this particular example it's because the caller - email@example.com - is a Third Party Trust and the, "owning" Account is using Hybrid Conversion. Had the owning Account used Double Conversion, then Third Party shared access would have been available for Restore by the owner. This is one of the many differences between Hybrid and Double Conversion, more fully explained in the article, Operating Modes.
For more in-depth operational details, refer to the article, Restoring and Replicating.
Notice the example Versionlist shows a different Hash for each Versoin. This indicates that the file's plaintext content was changed. If however the file was opened and subsequently closed without modification, you would see two Versions with the same Hash value.
The Hash can be derived using MD5 or SHA1, which is determined for an Organization in the License and Components Interface. Though all Users can view those settings, only Privileged Accounts can make changes (due to the impact across Organization Accounts).
The set of :Recover KODiAC Archive files (for the calling Account) - the Archivelist - appears in the Managed Files/ Restore display after choosing the Archive... button. For our previous example, content is as follows:
The Archivelist enumerates the latest version of each :Recover-stored file.
Notice, in our example, the familiar contact_list.xlsx from the initial Versionlist shows Version 3, not Version 4. As previously noted, items with Size=0 are not in the Archive, and as a result this list does not reflect the presence of Version 4. When executing Restore, Version 3 will be the first considered candidate. However, we also know from before that Version 3 was created by a Third Party Trust and, since we're using Hybrid Conversion, it is also unavailable for recall even by the, "owner". As such, Restore operation, for this file from either this Archivelist or the Hostlist, acquires Version 2.
Restore/ Replicate operation is detailed in the article, Restoring and Replicating.
File Size Details
Astute observers will have noticed that the Size shown in the Archivelist differs than that shown in the Versionlist.
Archivelist values reflect plaintext content Size for the related Version, whereas the Versionlist value represents an interim host-specific ciphertext Size that's useful when conducting Forensic Analysis and reconstructing data to track attacker actions. For details, contact your DefiniSec Representative.
File Date/ Time Values
Date/Time information should match Windows Explorer figures - specifically the Last Modified value in a file's Explorer Properties display - of course with the caveat that Managed Files/ Restore displays enumerate content using UTC/ GMT values to align with :Assess Report data.
Host List Date/Time values may in certain cases be missing, replaced with, "N/A". This indicates that a host-local version could not be found and/ or read, and also that an associated instance could not be identified in the Archive or data history. This can be encountered when a conversion operation is destructively interrupted, for example by removing power (from a desktop or workstation that doesn't have or use a battery).
Finally, if a file's Host List State does not match what's found in local storage, the Date/Time value will include an asterisk. This is a rare error condition that should seldom (if ever) be observed, and as a result warrants further investigation if/ when present.
Archivelist File Hashes
The Versionlist Hash value reflects plaintext computation, as noted above. Note that both plaintext and ciphertext hashes can be found in associated :Assess File Report entries.
The Archivelist only displays Hash data when the associated Filename cannot be decrypted, often the result of a critical failure while accessing managed content. This is seen when the Filename is replaced by the unique File ID, and the Path replaced by the (plaintext) Hash.
Archive List Functions
Controls are nearly the same as those described in the article, Managing Host Data, except as noted in the next section. This holds true for column-based sorting, and as you may notice, Lists are first displayed with most recent items at the top, descending by GMT date/ time associated with the item's last secured write/ close operation.
As expected, you can Filter/ Clear using the controls described for the Hostlist (don't forget the Filter retains its' entry when navigating to other List displays), and you can also choose an item then Open Folder to open File Explorer in the target's native folder. If for some reason the native location has been removed, File Explorer will display the Default Folder.
Static Load, Refresh for Changes
The Managed Files/ Restore Lists are loaded and enumerated when you navigate to the context menu and choose to display content. As you perform operations and move from one List to another, you will find a need to see updated values. Use the Refresh button from any of the three displays to render updated content.
IMPORTANT: Remember that switching from one List view to another does NOT refresh content, for performance reasons - though it may be re-sorted (until these proceedings are further optimized).
Archive and Hostlist Divergence
Hostlist functionality differs from the Archivelist for Clean and Refresh operations, which are described below. Opt Filter is not available from the Archivelist, though Replicate is unique to the Archivelist and not enabled elsewhere. Additional Replicate details are available in the aforementioned articles further detailing :Recover.
The Archivelist can be quite long, and Archive Filenames are not stored in plaintext. For this reason, creating the plaintext enumeration can be time-consuming, and for long lists takes more than a few seconds to complete.
For this reason, SSProtect keeps and refers to interim data that maintains state for all known entries, providing quicker secured access to changes (though this is not a true cache). Interim data is updated on the fly, each time application logic or end-user actions refer to Archivelist resources. This allows you to perform Archivelist Refresh operations that return updated information more quickly.
Cleaning the Archive List
Archivelist Clean removes the above-noted interim data then re-acquires all content going back to the very first day your Account was used. This can take some time after a couple years of use, as each entry can take upwards of 4-5s to process, depending on your host computer and dependency details.
Note that you shouldn't have a need to Clean your Archivelist except when troubleshooting issues.
For More Information
For information regarding product features and content, consult the Document Index, or send email with specific questions to firstname.lastname@example.org.
This article was updated w/ v9.6.1 of the :Foundation Client