Security Best Practices

When setting up monitoring services you may have data which you wish to secure within the web console. A good example of this type of data is a username or password for a site login, or a secret key used to access a web service API. This guide will explain the security features of the web console as well as best practices for ensuring your sensitive data remains secure.

Scope of this guide

This guide refers ONLY to preventing sensitive data from being displayed within the web console. Any other type of security, including the transport of data within the GlobalWatch network, is outside the scope of this document.

Security Basics

The web console offers the ability to encrypt bits of text, such as a username or password, using an industry-standard implementation of the Blowfish Algorithm . The web console provides a utility to secure sensitive data which takes the provided sensitive text and returns a string to be used for configuring the settings of the particular monitoring service. This utility is accessible from the settings page of the monitoring services as well as from the links below. There are currently two versions of this utility. Please refer to the utilities themselves for usage instructions:

Monitoring Service Type Description
Rich Internet Application Monitor Utility Includes all service levels of the Rich Internet Application monitoring product.
Standard Internet Application Monitor Utility Includes all service levels of the Application Monitoring, Stream Monitoring, and Web Service monitoring products.

Ensuring Data Security

Once you have obtained a secure version of the sensitive username or password to be used in the service settings, there are certain steps you must take to ensure that the information remains protected. Below are several examples to follow to secure sensitive data for each type of monitoring service that supports this feature.

Application Monitoring

  • Monitoring services using POST as a transport method.
    • Non-secure data transmitted via the POST transport method will only be displayed when performing a "Save & Test" operation or when an error occurs during monitoring. In both of these cases, securing the data with the above mentioned utility will ensure that it is obfuscated from the results.
    • Example of secure formdata:
  • Monitoring services using GET as a transport method DO NOT guarantee security. The monitoring system records the full URL used to access a page, as well as items on that page. Secure data within a URL or within GET formdata may be exposed in graphs, reports, as well as while running diagnostic operations from the Diagnose tab.
  • Using secure data in any other place in the monitoring script other than POST formdata DOES NOT guarantee security. Parameters such as search strings, error keywords, and URLs may show up in their plain text form in certain areas of the control panel.

Stream Monitoring

  • Stream Monitoring username and passwords are not displayed anywhere except on the settings page of the service. Securing these there will ensure they will not be visible anywhere else within the web console.
  • Using secure data in the StreamMonitor URL itself DOES NOT guarantee security. The URL is recorded by the system in its plain text form and may be displayed in graphs or reports, as well as while running diagnostic operations.
  • Example of secure username/password:

Web Service Monitoring and Web Service Transaction Monitoring

  • Similar to Application Monitoring, the best way to secure data for these service types is by including it in the transport payload parameter to be transmitted via the POST transport method. Including secured data anywhere else within the settings page does not guarantee its security.
    • Defined variables for a service can be secured are only guaranteed to be secure as long as they are used within the data transmitted via the POST transport method and nowhere else in the settings.
  • Example of a secure variable being used in a POST request:
  • Monitoring services using GET as a transport method DO NOT guarantee security.

Rich Internet Application Monitoring (RIA)

  • Data that is submitted via the POST transport method is guaranteed to be secure.
  • RIA monitors use Internet Explorer 7 as a monitoring engine. Since usernames and passwords will usually be filled in by setting values of input fields and forms submitted by clicking on links or buttons, it can be more difficult to determine whether data is being sent via the GET or POST method.
    • The best way to examine whether data is being submitted by POST is to check the Instacheck output for the sensitive data you wish to hide. If it is present, the script may need to be re-recorded or manually adjusted. Please contact Webmetrics Support at or 877-524-8299 x2 for assistance.
  • Example of secure username and password for a RIA monitor:
  • Data that is submitted via the GET transport method is not guaranteed to be secure, as it can show up in graphs/reports, as well as while running diagnostic operations.

See also