This article shows you how to Restore content created in the Protect and Access Data Walkthrough.
Introduction
SSProtect encrypts and protects host application data files and Microsoft Outlook email message content. The underlying procedures are carried out such that they are connected to other built-in or optional services.
This article shows you how to Restore content Protected and Accessed in the Walkthrough, Protect and Access Data, when using an Account with the optional service SSProtect :Recover.
Prerequisites
This article assumes you have downloaded and installed the :Foundation Client as described in the article, Installing the :Foundation Client., and have worked through the STEP guidance in the article, Protect and Access Data (preferably using a Test Account with guidance in the article, Introduction and Preparation).
Enumerating Managed Content
If necessary, login to SSProtect using Refresh Login from the context menu available by right-clicking the SSProtect icon in the notification tray.
STEP 1: Use the SSProtect notification icon's context menu and select Managed Files/ Restore to display the Managed Hostlist:
This display enumerates Managed Content and associated State for the active Login Session's Account on the current host computer. If you completed the STEP guidance in the Walkthrough, Protect and Access Data, your display will match the one shown above.
The Managed Files display, or Hostlist, is your point of entry for managing SSProtect'd data. In this case, we see three files in the Protected State, and one file in the (Released) State. Further details are available in the article, Managing Host Data.
Enumerating Versions
STEP 2: Select TestDocument.docx (not .pdf) then click Versions... to display the Versionlist:
The Managed Versions display, or Versionlist, shows historical instances of the chosen file (noted at the top). This will include instances created by authorized sharing peers and Third Party Trusts, reflected in the Username column.
Take a look at the Size column, and compare that to the size of the protected file in File Explorer; they don't match. Versionlist Size is for the plaintext used to create the protected Version (correlating to the value in the Plaintext Hash column). If an instance was created without :Recover, or it was created with Optimized Offloading, the Size would display as zero (0).
Plaintext Hash is exactly as noted, here in MD5 form (which can be changed to use SHA-1 in the License and Component dialog). Because Version 1 and Version 2 have the same Plaintext Hash value, you know that source material did not change, despite that v1 and v2 use different keys and as a result, hold different ciphertext.
This article is most interested in the value of the right-most, "A" (Availability) column, which will show, "Y" or, "-" to indicate whether or not your Account can Restore the associated Version.
STEP 3: Select the Version 1 instance, click Restore then Open Folder to display File Explorer:
Notice the Restored file includes the suffix, -v1; The Version suffix is unique to Restore carried out from the Versionlist, and it reflects the instance that was chosen.
You can of course select more than one Version at a time, then execute Restore to obtain each instance. Further insight on the Versionlist is available in the article, Managing Archive Data.
Looking Deeper: Explorer Overlay Icon Rendering
Note from our most recent File Explorer display that the Restored file's Overlay icon is Yellow. If you followed along in previous Walkthroughs, you know that Managed Content does not include identification details tying it to any Account/ User. For the :Foundation Client to maintain proper and continuous insight into a Managed Item's state, then, it would at the very least have to maintain visibility over all related activities such as copy, move, and rename. This isn't practical, especially considering that content can move to/ from hosts with and without SSProtect.
For these, and many other reasons (performance), File Explorer Overlay Icon rendering uses stateless logic. Though you know you've Restored an instance of a file in a Version Chain that your Login Session's Account owns, unless and until you access the renamed file, it will remain in the indeterminate access state depicted by the Yellow Overlay Icon.
If (but don't do this now, it'll pollute result clarity and we'll return to it later) you were to securely access the -v1 instance, on save/ close SSProtect would execute Managed Close, the automatic re-encryption/ protection of the Managed File. This would turn the Overlay Icon Red and the Hostlist would contain the new entry for the target file.* This proceeding relates to an advanced topic - Version Chaining - described in the article, Version Chain Policy and covered in the Walkthrough, Version Chains.
* The new Version of the -v1 file would in fact be Version 3. The noted Version Chain Walkthrough will show you how this functions.
Restore the Latest Version
Our previous operation Restored a specific Version - let's return to the Hostlist and let SSProtect find the most recent instance for us:
STEP 4: Return to the Managed Files (Hostlist) by clicking Host List..., then choose TestDocument.docx before clicking Restore. Choose Replace when prompted to overwrite the existing file, then click Open Folder to see the results:
When executing Restore from the Hostlist, SSProtect will acquire the Latest Qualified Version of the target, which in this case happens to be Version 2. You can verify that the -v1 instance and the .docx instance are different. Let's do that now:
STEP 5: Hold the Shift key and right-click TestDocument-v1.docx, then choose SSProtect Release. Double-click the now-plaintext (Released) instance and you'll see that the body of the document contains content from the Version 1 instance we first created and protected.
Finally, a little housecleaning.
STEP 6: Return to the Managed Files (Hostlist) UI pane, then select TestDocument.pdf and click Remove. Confirm the operation with Yes.
Advanced Topics: Qualified Versions
The Latest Qualified Version, available for Restore, may not be the latest Version in the Version Chain. Determination becomes more complex when you share content with Organization Peers and Third Party Trusts, and details further depend on the Operating Mode used for each individual instance.
Further insight is offered in the article, Restoring and Replicating. Replicate is discussed below, and the Walkthrough, :Recover w/ Shared Content, revisits this concept in specific STEP guidance.
Looking Deeper: Non-Destructive Restore
In general SSProtect does not delete or erase information. As you can see from the Restore operation where we chose to Replace existing content, the software moved the file to TestDocument.docx.bak, ensuring we would be able to access replaced content.
In fact, if you were to execute the same Restore/ Replace operation again, from the Hostlist or any other dialog, the software would extend the operation to maintain the backup as follows:
- TestDocument.docx.bak would be moved to TestDocument.docx.bak.0
- TestDocument.docx would be moved to (the now vacant) TestDocument.docx.bak
- TestDocument.docx would be written with the latest appropriate Version from the KODiAC Archive
You will find that almost all :Foundation Client activities perform similar operations to ensure content isn't permanently removed (for example with Sabotage/ Integrity Remediation and related Integrity Protection activities). In the very rare case(s) that don't keep backups, you'll find that the removed entity is available in other ways.
KODiAC Managed Data Archive
KODiAC (Cloud) Services manages all :Recover content, making it available not only for Restore operation, but also for :xRecovery Disaster Recovery services and also :Respond Integrity/ Sabotage Remediation.
You can view the complete set of data items available to your Account by navigating to the Archivelist:
STEP 7: From the Managed Files (Hostlist) display, click Archive... to display the KODiAC Managed Data Archive:
In our progression, this list is nearly the same as the Managed Files list except for the one item - TestDocument.pdf. Since it had been (Released), there was no reason not to Remove it from active Hostlist enumeration. You cannot, however, remove its' presence from the Archivelist, where it remains available for Restore operation.
Over time, you will find that the set of files in the Hostlist will more dramatically diverge from those in the Archivelist. Whereas Managed Files (Hostlist) is the point of entry for active SSProtect'd content (on a given host computer), Managed Archive (Archivelist) is the point of entry for all content available in the KODiAC Managed Data Archive due to :Recover usage, for your Account. For this reason, the set of columns is slightly different from those in the Hostlist and Versionlist.
You can, of course, carry out activities from the Archivelist that are similar if not the same as those in the Hostlist. Restore, as you may have suspected, finds and acquires the Latest Qualified Version of a Managed File.
:Recover for Data Loss (Manual)
What if you sat down to your computer and found out that, for whatever reason, your data had been erased? Let's see how SSProtect helps.
Note that this sequence uses manual operations that can be automated when using :Respond Remediation. Check back for updates to these Walkthroughs for upcoming details.
STEP 8: From File Explorer, delete the whole Folder C:\TestData. Return to the Archivelist, select all (four) items then click Restore.
STEP 9: In the Archivelist, check Log Restore then click Replicate. Choose Open Folder to display the results:
As expected, we've acquired the Latest Qualified Version of each Managed Item by executing the Restore operation. We also have a new subfolder, C, which is the result of the Replicate operation.
Drilldown into the C:\TestData\C folder and you will see a, "replica" of Restored C:\TestData content, i.e. C:\TestData\C\TestData. As you will see below, this is intended to serve as a source for relocating content to, "destination" folders on the active host computer.
:Recover Replicate Operation*
Replicate restores each Managed Item in a location that mirrors the Qualified Version's path, however inside your Default Folder to ensure the intended folder structure can be created. If you have Managed Content in locations from other Volumes, they will be included as, "top level subfolders" e.g. D, E, etc.
This is helpful when working on multiple host computers that use different Volume mappings for mass storage, when working with data using temporary Volume mappings associated with removable media, and also with real working data that is stored in a variety of disparate target locations that might not be available on all (relevant) host computers.
Additional information is offered in the article, Restoring and Replicating.
* Do not confuse :Foundation Client Replicate operations with KODiAC Replication, a way for you to control global :Recover content access and distribution.
:Recover Replicate to Source Data
In general, you should use Replicated content as the reliable source and starting point for relocating Managed Items to, "permanent" target working locations. If instead you access content inside a replica instance, you will create new Hostlist entries for those specific locations - for example, C:\TestData\C\TestData\Test.txt. Subsequent Replicate operation would then add yet another layer of, "indirection".
Use Replicate results as a means of acquiring content, and be sure to relocate items before enagaging Managed Access operations.
:Recover Details in the Host Debug Log
In Step 8, we guided you to check, Log Restore before executing Replicate. This forces an entry in your Host Debug Log for each individual Restore operation, helpful when verifying and troubleshooting details.
STEP 10: Click Show Log* to display the Host Debug Log then uncheck Log Restore (else it remains checked for future operations).
This opens Notepad with activities specific to your Account's operation on the active host during the current day. Scroll to the bottom to find and review Replicate operation details, which should look similar to the following:
00003884 - [2020/09/22-16:15:40.654] -INFO- FileConfig ===:Recover Rebuild=== Attempting to Rebuild 4 files
00003884 - [2020/09/22-16:15:41.365] -INFO- FileConfig == Rebuilt with Success: C:\TestData\C\TestData\Test.txt
00003884 - [2020/09/22-16:15:41.539] -INFO- FileConfig == Rebuilt with Success: C:\TestData\C\TestData\TestDocument.pdf
00003884 - [2020/09/22-16:15:41.712] -INFO- FileConfig == Rebuilt with Success: C:\TestData\C\TestData\TestDocument.docx
00003884 - [2020/09/22-16:15:41.904] -INFO- FileConfig == Rebuilt with Success: C:\TestData\C\TestData\TestWorkbook.xlsx
00003884 - [2020/09/22-16:15:41.904] -INFO- FileConfig ===:Recover Rebuild=== Operation Complete
Use these entries when you need to verify Restore/ Replicate operation, in detail, and/ or troubleshoot individual problems.
Finally, note that the setting, Log Restore, is, "sticky" for your host computer in that it retains its' last setting even if you Exit the :Foundation Client then restart and login to another Profile. As such, if you don't want to record individual results for every Restore operation (and endure the overhead, which isn't insignificant with large numbers of very small files), be sure to remove the check before dismissing the dialog.
* You can access your Account's Host Debug Log using Display Logfile in the context menu.
Looking Deeper: Critical Role of :Recover
SSProtect Conversion is an all or nothing proposition, and patented cryptographic offloading includes built-in :Recover primitives. As a result, unlike traditional Backup/ Restore, content is updated with each committed change to Managed Content while remaining Highly Available to maintain business continuity in the most challenging network and host dynamics.
:Foundation Client Protect operations utilize KODiAC-specific commit procedures that require :Recover content to be verified in multiple storage destinations before endpoint (host) Conversion completes with success. Added latency is absorbed independent from end-user activities, very seldom limiting forward operation. Even then, the cost burden is extraordinarily low. Subsequent 2nd-stage KODiAC :Recover processing migrates data to intermediate- and long-term storage based on KODiAC Replication Policies defined by Privileged Organization Users. Policy determines regional storage requirements and remote regional access capabilities, all carried out with very specific attention to details that ensure KODiAC (Cloud) Service operators (MSPs) cannot access end-user plaintext at any time - even when malicious insiders monitor and obtain all associated KODiAC (Cloud) Services resources over the lifetime of a Managed Item.
In fact, under the covers, access to KODiAC Managed Data purposely utilizes the same logic and routines that are invoked when carrying out Managed Access operations (from the :Foundation Client or :Expand API). This ensures that KODiAC-stored :Recover content is available only in protected form, requiring SSProtect authentication and authorization implemented with :Access MFA and :Confidential cryptographic offloading. All transactions include native KODiAC (Cloud) Service :Assess Auditing for a precise, reliable, and secured record of operations used for tracking, reporting, and analysis.
:Recover is the sole source for :xRecovery Disaster Recovery services, offering secure, offline access to all Managed Content in an Organization. :Recover serves a different purpose when delivering assured integrity for :Respond Remediation, repairing Sabotaged and Ransomware'd data with minimal disruption.
SSProtect , with its' integrated suite of Data Protection and Management facilities, delivers a practical, scalable, robust and secure platform that reduces the scope and impact of malicious intent aimed at sensitive, confidential and Intellectual Property data. Whether attacked by malicious insiders, ex-employees, determined high-end hackers for hire, and/ or well-funded nation-state APTs, SSProtect gives you the facilities to maintain operational continuity and the tools necessary to investigate, track, and prosecute those responsible for what would otherwise be catastrophic intrusions and data breach incidents.
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/ v10.7.1 of the :Foundation Client