September 2, 2015

Why You Should Secure Your TestTrack Server (And How To Do It)

Helix ALM
secure TTTestTrack server security might not be something you've thought about, but it can be a way for hackers to gain valuable information about security flaws in your product. Let's look at why you should be concerned and how you can improve the security of your TestTrack server.

Why should I be concerned?

Put simply: The cost of enabling a few security options in TestTrack is miniscule. The cost (and by extension, risk) of being breached is not—and is potentially limitless. The modern network security landscape is one where there is no such thing as being too paranoid. The word is out that certain government agencies and other wealthy, unscrupulous entities will pay thousands of dollars—no questions asked—for the technical details of software security flaws. And where is the accumulated knowledge of all known security flaws in your product, past and present? Look no further than your issue tracking tool! This means breaching your issue tracking tool could be a payday worth tens of thousands of dollars for a shrewd and equally skilled hacker. Supposing such a hacker strikes pay dirt, what happens then? After purchase the buyer uses those technical details to develop malware that exploits the security flaw. This malware might use the software as a vector to install backdoors or other malware. It might steal top secret information, trade secrets, or passwords. Or worse, sabotage critical equipment.

What should I do?

Keep your TestTrack installation up to date

All the patches in the world can't protect you if they aren't installed. Flaws are occasionally found in TestTrack itself and the third-party technology that TestTrack relies on, most significantly OpenSSL, which TestTrack uses to encrypt communication. OpenSSL flaws have been big news lately (remember Heartbleed?). When new flaws are announced you can determine whether your TestTrack Server is at risk by comparing the vulnerable OpenSSL versions to the OpenSSL version in your TestTrack server.
  • The vulnerable OpenSSL versions can be determined from the security advisories on OpenSSL.org, such as this one for Heartbleed.
  • Your TestTrack Server's OpenSSL version is shown in the TestTrack Server Admin Utility. Click Server Options and select the Security category. The OpenSSL version is at the bottom of the dialog box. (Applies to TestTrack 2014.1 and later only. Most TestTrack versions before 2014.1 use OpenSSL 0.9.8k)

Don't assume your LAN protects you

Many people fall into the trap of thinking that because they only access TestTrack from within their corporate LAN that security isn't a concern. Not true—many hacks are perpetrated with the (often unwitting) help of an organization insider. One insecure configuration and a mistake by someone inside (even someone without access to TestTrack) might make a hacker's month.

Never run TestTrack without encryption

At a bare minimum, you should never run TestTrack without encryption unless you live in a country that restricts the use of encryption. You can turn on encryption in the TestTrack Server Admin Utility. Click Server Options and select the Security category. Then, select the ’Encrypt communication between clients and the server‘ option. You should also enable the ’Enforce security over backward compatibility if conflicts occur’ option. [caption id="attachment_17362" align="aligncenter" width="741"]TestTrack's Server Security Options Figure 1: TestTrack's server security options[/caption]

Never run the TestTrack Web components without HTTPS

All modern web applications rely on HTTPS for security. TestTrack Web is no exception.

Use 64-bit SOAP cookies

If you use SOAP, enable 64-bit cookies in the TestTrack Registry Utility. Click CGI Options and select ‘Use 64-bit SOAP cookies’. Verify that your SOAP app can handle 64-bit cookies before enabling this option. [caption id="attachment_17363" align="aligncenter" width="456"]TestTrack's SOAP Options Figure 2: TestTrack's SOAP options[/caption]

Use RSA key exchange

Encryption alone cannot prevent the most sophisticated modern hacks. An additional mechanism, one that allows the TestTrack Client initiating the connection detect attempts to impersonate the TestTrack Server, is required to solve this problem. TestTrack's RSA key exchange option is such a mechanism. With this option enabled and the proper key installed on each TestTrack Client, the identity of the TestTrack Server is verified independently by every TestTrack client, every time it connects. If a hacker without the server's private key attempts to impersonate the TestTrack Server, the TestTrack Client drops the connection without sending any sensitive information and informs the user.
  • Without RSA key exchange, passwords to your TestTrack installation (or your whole network, if they are the same) are at risk to sufficiently sophisticated hackers.
  • Security of the RSA key exchange option is not contingent on keeping the public key file out of questionable hands.
  • Security of the RSA key exchange option is contingent on verifying that the imported public key file's fingerprint (shown in the server configuration dialog box in the TestTrack Client) against the fingerprint shown in the TestTrack Server Admin Utility.
[caption id="attachment_17364" align="aligncenter" width="523"]TestTrack Server Options Figure 3: TestTrack's server options[/caption]

Need more information?

More information about securing communication between clients and the TestTrack Server can be found in our online help. You can also find some helpful information in the Keeping the Hackers Out – Securing Client/Server Communication blog post.