Ransomware is troublesome news all over the world.

This FAQ is designed to help our customers understand how to deal with them if they affect the StrongKey Tellaro (“Tellaro” or “SAKA”) appliance. If you have a specific question not addressed here, please send an e-mail to This email address is being protected from spambots. You need JavaScript enabled to view it..

FAQ

1. Can ransomware threats affect the Tellaro?
   Indeed, they can. Ransomware can affect any system and file if the malware is designed to operate on that specific operating system and has the appropriate privileges. While most ransomware are generally targeted at Microsoft Windows (because of their general prevalence in the market), ransomware can be written to execute successfully on any platform.
   
   
2. How can it affect the Tellaro?
   Since the Tellaro operates on a general purpose operating system (CentOS Linux) and uses industry standard software (Payara, MariaDB, OpenJDK, Bouncy Castle, etc.), ransomware designed to execute on Linux environments with the root account can encrypt all files on the appliance. Ransomware operating with the strongauth account can only encrypt files on the /usr/local/strongauth file-system – but that's sufficient to lock up the appliance and prevent cryptographic services being available to support applications.
   
   
3. How can I mitigate the risk of ransomware affecting the Tellaro?
   Given that most Tellaro appliances are used to comply with regulations such as PCI-DSS, GDPR, HIPAA, etc., these rules should be considered when operating the Tellaro appliances within your environment. However, please use your company’s policy to adjust these recommendations to your needs:
   
   a. Limit network access to the appliances only to authorized applications. Segment the Tellaros into their own sub-network and place firewall/access control rules at the router/switch to allow traffic to enter the sub-network only from TCP/IP addresses authorized to call webservices on the Tellaro – every other TCP/IP address should be denied access to the Tellaro sub-network. This policy will ensure that the Tellaros can only be compromised if the application systems using Tellaro webservices are breached first;
   
   b. Limit the number of authorized people who have physical access to the Tellaros. These are people who are responsible for the Operations, Administration & Maintenance (OAM) of the Tellaros. The fewer people have access to the hardware, the lower the probability of inserting untrusted/infected USB flash-drives that might propagate ransomware;
   
   c. Limit the number of authorized people who have logical access to the Tellaros. These are people who have Key Custodian and/or Domain Administrator access to the appliances. These people need to be able to use tools that must have direct access to the appliances’ webservice port. If possible, use a virtual machine on the same sub-network as the Tellaros to provide access to constrain machines outside the sub-network from accessing the Tellaro;
   
   d. Lock down the root credential. This process is described in the Tellaro Reference Manual. While it does increase the complexity of OAM operations, it will ensure that ransomware cannot gain access to root credentials inadvertently;
   
   e. Use a controlled process when transferring patches/updates to the Tellaros. Since this is not a frequent activity, it might be appropriate to verify the SHA256 message digest (hash) of every file that is transferred to the Tellaro, and to have the files/hashes verified by another person before they are transferred to the Tellaro for patching/updates. (A simple process might be to have Person-1 transfer files/hashes from their machine to a “bastion host” that bridges Person-1’s PC to the Tellaros, while Person-2 verifies files/hashes on the bastion host and transfers it to the Tellaros. Super-paranoid organizations may have yet another person, Person-3, perform the actual patching/upgrade on the Tellaros, if necessary);
   
   f. Export the contents of the MariaDB Relational Database Management System (RDBMS) frequently and store the exported file offline. A full database export once a week and incremental backups on a daily basis will provide a measure of safety to recover as much data as possible quickly. Since all sensitive data within the exported file is encrypted – and can be decrypted only within the Tellaro cluster using the cryptographic hardware module within the customer’s Tellaros – there is no reason to apply any further protection on the exported file for offline storage.
   
   
4. How can I recover the Tellaro cluster if one or more – but not all - nodes are affected?
   In the unfortunate circumstance a Tellaro is compromised by ransomware and does not respond to service requests under any circumstances, as long as one functional Tellaro is available with a current copy of the configuration and database, it is possible to recover all remaining Tellaros to their current state – even if it requires installing the appliance from scratch.
   
   A critical safety barrier on the Tellaros is the cryptographic hardware module (TPM or HSM) that protects the Master Key of the appliance within the hardware; this module is impervious to attacks short of reinitialization or physical tampering attacks. With this safety measure, it is possible to rebuild the software stack on the hard disk of the appliance and have it recognize its Master Key in the cryptographic hardware module to decrypt its key-hierarchy and encrypted data.
   
   At a high level, the recovery process consists of the following steps:
   a. Installing the operating system that operates within your cluster;
   b. Installing the Tellaro software stack that operates within your cluster;
   c. Copying over appropriate configuration files from a “sane” (uncompromised) Tellaro;
   d. Importing the database contents from a “sane” Tellaro;
   e. Restarting the Tellaro and activating the appliance using Key Custodians;
   f. Verifying that replication has synchronized the rebuilt Tellaro with the “sane” version;
   g. Applying new mitigations to the cluster to prevent a repetition of the compromise.
   
   
5. How can I recover the Tellaro cluster if all nodes are affected?
   This is the only scenario that can, potentially, cause the loss of all encrypted data. However, depending on the Tellaro appliances you have within your cluster, this may be just a process of restoring data and keys from a “sane” (uncompromised) backup. If the Tellaros in your cluster use a FIPS 140-2 Level-3 Hardware Security Module (HSM), and if you have a “sane” backup of the following, you can recover the Tellaro appliances to the last backup point:
   a. Smartcards that represent the Master Backup Key (MBK);
   b. An encrypted export of the contents of the HSM;
   c. An export of the MariaDB database with its encrypted data and keys;
   
   The recovery process for Tellaros with HSMs is similar to the recovery process described in the answer to the earlier question, with the addition of a step that restores HSM keys to the HSMs from the encrypted backups using the MBK on smartcards stored offline.
   
   If the Tellaros in your cluster use a FIPS 140-2 Level-2 Trusted Platform Module (TPM), and if you have a “sane” backup Tellaro appliance along with a recent backup of the MariaDB database, you can recover the Tellaro appliances to the last backup point. The question, however, is: if all Tellaros in Production mode on the network have been compromised, how does one restore the production Tellaro cluster?
   
   The answer is: Because TPMs do not provide the ability to backup Master Keys to an offline encrypted file or smartcards, the only offline backup can be another Tellaro with a TPM cryptographic hardware module that has encrypted Cryptographic Domain Keys (CDK) migrated to the offline node.
   
   TPMs have the ability to migrate encrypted keys from one TPM to another. However, this requires that the encrypted CDKs were migrated before all online Tellaros are compromised by ransomware.
   
   In a production environment, StrongKey installs/configures the cluster so that encrypted CDKs are migrated to all nodes of the cluster. This allows the cluster to encrypt/decrypt data and keys across the cluster regardless of the node that originally encrypted data and/or keys. As long as the customer environment has an offline Tellaro with all CDKs migrated to that node, the only other requirement to recover all production Tellaro nodes is a recent backup of the MariaDB relational database management systems (RDBMS) contents.
   
   If the production Tellaro environment (with TPMs) does not have even a single “sane” Tellaro available, and all Tellaros are compromised by ransomware so that a recent copy of the /usr/local/strongauth file-system and database is unavailable, it will be impossible to recover from the compromise; the only recourse will be rebuild the cluster as a new one (with additional mitigations to prevent a repetition of the compromise).
   
   We recognize that this is not what customers would want to hear. While the security design of the Tellaro provided for adequate levels of protection and backup, there are mitigation steps that customers must take into account to protect their environment.
   
   

   NOTE: If you would like to discuss the procurement of an entry-level Tellaro appliance with a TPM to serve as an offline backup to your cluster as a mitigation strategy, please get in touch with us. StrongKey is willing to accommodate customers as best it can towards helping make this mitigation possible.

6. Can the Tellaro be used to mitigate ransomware threats affecting files on other systems?
   StrongKey has a web application, CryptoCabinet, that works in conjunction with the key management module within the Tellaro appliances to mitigate the risk of ransomware threats. The mitigation relies upon a novel feature of the strongest authentication protocol created in the last half-century: FIDO/WebAuthn
   
   Unlike any other authentication protocol, a unique capability of FIDO is that it mandates a “test of user presence” for authentication to a web application. The “test of user presence” usually requires a human being to perform an overt action with a physical Authenticator – either by providing a biometric to a fingerprint/face reader (built into the laptop/desktop computer), typing in a PIN on a keyboard, or touching a metallic surface on an external Security Key connected to the user’s computer.
   
   Ransomware rely upon executing with the privileges of an authenticated user to lock-up files to which the user has write-access – they cannot perform actions that were designed for human beings to perform overt actions that software cannot perform. As a result, ransomware cannot successfully authenticate themselves to web applications protected by FIDO.
   
   StrongKey CryptoCabinet leverages this feature to create a secure repository of encrypted files (whose encryption keys are escrowed within Tellaro appliances using the same process customers use to encrypt/tokenize their sensitive data) and delivers this web application with FIDO authentication being the only way to authorized mechanism to access the repository.
   
   This does require that users interacting with sensitive files must retrain themselves to store sensitive files in CryptoCabinet using a web browser, and retrieve them through the browser before operating on them with their application.
   
   

   NOTE: If you would like to see how CryptoCabinet works, please feel free to use a modern web browser – not Internet Explorer – to https://demo.strongkey.com and see for yourself. You can test CryptoCabinet with the following – just remember to use a current version of the browser in all cases:  - Microsoft Windows 10 configured with Windows Hello + Edge/Chrome/Firefox  - MacBook Pro with TouchID + Chrome/Safari  - Android 9 or greater with Chrome  - iPhone with iOS 14 or greater + Safari  - Any computer with an external Security Key + Brave/Chrome/Edge/Firefox/Opera Use the Sign Up link at the bottom of the splash-page and register a free account. Once you have registered a FIDO key with the site and are authenticated to the application, click on CryptoCabinet and then, Cloud Repository on the left-hand side of your screen. While the display only shows AWS, the web application supports storing encrypted files to seven (7) different cloud storage providers while the decryption keys always remain on the Tellaro. PLEASE DO NOT TEST WITH SENSITIVE INFORMATION ON THIS APPLIANCE. If you would like to learn more about CryptoCabinet, please don’t hesitate to contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .