How can Support Automation traffic be secured?


Article ID: 19844


Updated On:


CA Service Management - Asset Portfolio Management CA Service Management - Service Desk Manager



Information related to Support Automation session encryption


It is notoriously possible to attack web applications through campaigns aimed at causing buffer overruns, by sending requests that would execute commands maliciously or simple denial of service attacks where the server is flooded with a huge number of requests in a very short time period in an attempt to bring the server down.

There are two entry points that the SA application architecture exposes to the outside world. The first is the web server's port for receiving HTTP (usually port 8070) and/or HTTPS (usually port 8443) requests. The second is the application server's Support Automation socket server port - which can be any port configured by the system administrator, but typically 10443. The first of these is provided by Apache Tomcat which is very secure against buffer overrun type attacks.

When the technician and customer user interface SA components interact with the web server over HTTP, they do so by tunneling using a proprietary binary format that is encrypted exactly as the requests sent to the socket server. It is not possible to cause any problems with the application by submitting HTTP requests with the web browser, as the protocol that is used is not text based. Even when not running HTTPS, Support Automation communication is encrypted.

When accessing the web page components of the application, form data is posted in plain text. The most important area to address is the technician login process. In environments where the technician login occurs over the Internet, it is advisable to utilize HTTPS, which will cause all traffic to be encrypted and to ensure than no sensitive data, such as passwords, is ever transferred in plain text.

The Support Automation socket server is similarly secure. All requests are encrypted using 168-bit TripleDES encryption. Additionally, all messages also carry a checksum. If a message is received with an incorrect checksum (as would be the case with an attack involving sending random data trying to cause a buffer overrun) it will not be processed by the server and the socket connection it was sent on is immediately terminated. All reads from the server are memory buffered in a limited size circular buffer that decouples the server processing from the socket reading and writing, thus providing a level of protection against buffer overrun issues. To execute a command maliciously would require the attacker to be able to construct a valid request for a valid,currently existing Support Automation session containing a request in the CA Support Automation proprietary binary format, to add a correct checksum, and to encrypt it with the appropriate encryption key. The likelihood of this occurring is virtually nil.

Protection from Denial of Service style attacks is best achieved with the deployment of an Intrusion Detection System (IDS). These typically monitor for port scans or a rapid succession of connection attempts from a single IP address and, if found, they prevent further connections from that IP address. This solution is equally appropriate for protecting the Support Automation socket server as it is for protecting a web server.


Component: SBAUTO