Before configuring the VTS/IS, you should understand the security issues surrounding VTS/IS and VIC communications.
Access to the VTS Internet Server is protected by the username/password credentials held for each application by SecurityManager. This is the sole protection that is afforded to a VTS Internet Server from unauthorized access. Therefore, these credentials must be securely guarded.
When credentials are transmitted between the VIC and the server, the username and the password are both transmitted using Base64-encoding. The encoding is public knowledge and is entirely reversible, i.e. the username and password can be easily extracted.
Credentials are secured by employing Transport Layer Security (TLS). This establishes an encrypted communications connection that is secure against decryption, replay attacks and many other hacking attempts. It is generally accepted that 128-bit SSL is sufficiently secure for financial transactions.
Note: These notes will refer to SSL (secure socket layer) security. SSL is an older technology and the term has become the de-facto name for internet security. While the term “SSL” is used here by convention, VTS does use the more modern Transport Layer Security.
It is strongly recommended that all systems that use the VIC over a WAN employ SSL to secure their communication.
To use SSL on a VTS/IS, you must purchase and install an SSL certificate (see SSL Certificates).
SSL security involves the server providing an X.509-compliant digital certificate to the client, permitting the client machine software (web browser) to positively validate that the server is truly genuine, and not a fake, before engaging in encrypted communication with the server. Only a Certifying Authority (CA) can issue an SSL certificate that a web browser or VIC will accept without warning you that the certificate cannot be properly validated. This means that you may use a "test" SSL certificate (available from most CAs), but will receive conspicuous warnings by both your web browser and VIC, ensuring that you cannot be accidentally "fooled" by a fake SSL certificate. Only a properly issued certificate for the correct host and domain name will be accepted silently. The domain name must usually be registered to your company and will be verified to be so by the CA.
The asymmetric keys used by SSL ensure that your VIC (only your VIC – no other VIC or other program) can decrypt the communication stream from the server. The keys also ensure that only the server to which you are talking can decrypt any communication from your VIC. Only after secure communication has been established are your authentication credentials supplied to the server.
Before a VTS Internet Client may download the ActiveX component and remotely access standard VTS applications running on the VTS/IS, it is necessary to address some additional security issues.
• Remote users must have a valid user account within the VTS applications they wish to access remotely using a VIC.
• User accounts of clients wishing to access VTS applications remotely on a VIC must have the "Internet Client" security privilege, which allows the user to remotely view the application using Microsoft Internet Explorer web browser.
• Consider the use of user groups when configuring the realms and user accounts for your application. Security namespaces enable you to segregate users and data within an application. The result is that users will only be permitted to view specific sets of pages or subsets of data based upon the group to which they belong. Detailed information on namespaces can be found in User Groups.
• You should consider whether you wish some pages within a standard VTS application to be protected from specific users, through the use of application privileges.
• It is possible to create an AutoLogon account that does not require any authentication. This should only be done if you have a closed intranet with no internet access, or if you wish to provide open access to a guest account.
Topics in this section: