Resource Administration Overview
Resource Administration is available for Privileged Users - Organization Administrators and Delegates - as well as Individual Account holders. Use the Administer Resources menu selection from the notification tray's SSProtect icon to manage the following:
- Organization and Privileged User key Import and Export
- Enhanced two-factor login authentication configuration using Duo Security
- Organization LOCKDOWN that temporarily suspends managed data access
- The target Update version for Organization Users
The last two items - LOCKDOWN and Update - are not available to Individual Account Holders due to relevance. The remainder of this article provides summary information for each topic along with links to specifics.
Key Import Export
A number of regulatory standards require Organizations to maintain control of cryptographic keys. This is useful for Disaster Recovery and for independent material access, and with SSProtect both Organization and Account Keys are used: 1) when resetting the password of an Individual Account or an Organization Administrator (or an Organization that operates with only one Administrator), and 2) when using :xRecovery to export and securely access :Recover Archive data offline.
IMPORTANT: Individual Account holders are required to Export Keys (a single operation) before continuing the first Login Session. For Organization Administrators, this is only necessary if operating without other Users (an Organization Delegate).
NOTE: Materials Exported from Administer Resources match those required when unlocking :xRecovery content as described in, Requesting an :xRecovery Archive.
Enhanced Two-Factor Authentication with Duo Security
The Administration interface contains the entrypoint for enhanced two-factor login authentication configuration described in detail here.
This feature requires coordinated action from two Privileged Users and DefiniSec Support, and temporarily suspends all access to data managed for an Organization. All subsequent attempts to access protected files and email will fail, with Organization Users receiving an error indicating that the Organization is in LOCKDOWN. Third Party Trusts will receive a message indicating that access is temporarily suspended, which is the same message presented when a Third Party Trust relationship is temporarily Disabled through the Sharing interface. For more information, refer to the article, Managing Third Party Trusts.
A successful LOCKDOWN request inhibits ongoing non-privileged User Login, though existing sessions persist and any protected files/ email opened at the time LOCKDOWN goes into effect get re-encrypted/ protected on close. At present, new content can still be added by Privileged Users who retain ongoing Login capabilities, though Unprivileged Users cannot add new material.
LOCKDOWN sends email notification to every authorized User in the Organization, both when engaged and when lifted. The impact is immediate in that any subsequent access request will fail, as previously noted.
For notification details, refer to the article, Email Notifications.
IMPORTANT: This is not the correct 1st response to intruder discovery, in most cases. This is explained in an article regarding Incident Response dynamics. LOCKDOWN is most suitable when an intruder or internal saboteur is caught in the act or once all surveillance of his/ her actions has been completed.
In order for a LOCKDOWN request to succeed:
- Qualified staff must first contact DefiniSec Support and submit a request to enable Organization LOCKDOWN. This process follows a procedure setup by the Organization when licenses are purchased, and determines which Organization representatives are authorized to make the request, and the information each must provide in order for the request to be Authenticated. On success, Support will enable LOCKDOWN capability, which remains valid for a period of 5 minutes.
- Each of the two Participating Administrators/ Delegates must hold Privileged Account status for a period of at least 5 days prior, inhibiting rogue Administrators/ Delegates from creating temporary Accounts to use in engaging LOCKDOWN independently.
- Each Participant must use hardware 2nd-factor authentication. If not configured, or if disabled, LOCKDOWN will not be presented in the GUI, and any attempt to bypass this inhibiting state results in failure by KODiAC Cloud Services.
- LOCKDOWN requests must be received within 20s of one another, as observed by KODiAC Cloud Services. If the 2nd request is received outside of the 20s window, the transaction is cancelled and both requests must be re-submitted. This must occur within the 5 minute period of time provided by the Support permissive.
This procedure retains consistency with the multi-party consent model implemented by the KODiAC Cloud Architecture. We recommend that personnel assigned to authorize action by DefiniSec Support work in roles different from SSProtect Administrator/ Delegate capacities, which then requires three individuals to LOCKDOWN access to an Organization's SSProtect'd content.
Serving the Unanticipated
Though the very point of the SSProtect is to limit breach damage by inhibiting mass-offloading of plaintext content, LOCKDOWN provides a fail-safe mechanism for unanticipated events.
Note that Individual Accounts cannot use the LOCKDOWN facility, though can contact Support and make a request to temporarily disable their Account. This request requires typical Authentication criteria that is less aggressive than stipulations for an Enterprise engagement.
Privileged Users are notified of Updates once they become available, though Unprivileged Users are not made aware until released by Organization Administrators and/or Delegates. This provides a mechanism for testing new releases before exposing them to end-users.
Use Set Version to update the Organization with the latest release shown in the text associated with the button. Note that Unprivileged Users must update before they can continue using the software, though each is given one, "free pass" so they can login and complete any critical tasks before going through the update process. Thus, subsequent login attempts fail until the software update is executed.
Further detail, and additional capabilities, are described in the article, Updating the :Foundation Client.
This article was updated w/ v9.1.0 of the :Foundation Client