Consequences of the Heartbleed bug:

Consequences of the Heartbleed bug:

We have been getting a few inquiries from users around the world about the recently unveiled Heartbleed security issue, and if the somewhat extreme measures needed by some of our competitors to keep their customers safe from it are also needed with BeAnywhere, so we decided to explain what consequences this issue has to our community:

– We do not use SSL on our user components (Agents, Applets and Consoles) in a way that could be affected by this bug. You do not need to change your passwords or update your agents because of this bug (but is advisable to do so regularly);

– Our sessions are encrypted end-to-end by the military-grade Rijndael algorithm (that has been chosen as the Advanced Encryption Standard), using 256-bit keys, which means that, even if we were able to capture data from our sessions (which we can’t), that data would be useless to us or to anyone. BeAnywhere sessions are not affected by Heartbleed in any way whatsoever;

– We do not store technician passwords on our BASE infrastructure or any device credentials that are used in the context of a session (those are completely encapsulated within the session itself, and encrypted accordingly);

A lot of our infrastructure obviously relies on SSL. Only a part of it could be affected by the Heartbleed OpenSSL problem, but have proactively taken the necessary measures to fix this issue on the affected servers and will continue to be vigilant about this or any security issues that come to our knowledge.

We would like to remind you of the multiple ways you have to add even more security to your network, both with BeAnywhere or with other remote access and support providers, and encourage you to follow these procedures:

– Change your OS password on a regular basis;
– Always lock your computer when you are not using it;
– Always keep your OS and programs updated (you can use our inSight Lite module to keep an eye on it in your network);
– Change your cloud services credentials frequently and use a two-factor authentication method when the cloud service supplies it (we do);
– Use proprietary authentication on all your devices (and do not use the same password to all your devices) or force the usage of local OS credentials to establish a session;
– Block the local execution of automation scripts, if you do not need this sort of feature;
– Force the need for local authorization of unattended sessions, when feasible;

PS: No company or software should be punished for facing a security risk like this. We are sure that all of our competitors that unfortunately are having tougher times with this bug are working their best to avoid any trouble to their customers. If you also work with another product, please do follow their instructions and do not give their support teams a hard time. To everyone else, please BeSafe.

Leave a Reply

Your email address will not be published. Required fields are marked *