Symantec SSL Visibility Appliance Reviews

We are a federal organization and we host sensitive data from all over the country. The nature of our data was enough for us to start thinking about mitigating the blind spots in our traffic and security. At the same time, we needed to provide an analytic solution.

The solution decrypts SSL traffic and integrates with our security solution.

Essentially, this device allows us to retrieve traffic and efficiently utilize our security solution to help our analytics detect threats. This was something that was lacking because our firewall was unable to see the encrypted traffic and they were very late to release the SSL off-loading functions.

Since implementing this solution, we have enhanced our detection rates and our proxy.

There are a lot of noticeable benefits including the ability to categorize and detect a lot of URLs, hostnames, and file types.

This solution is really easy to deploy as long as the implementer understands PKI as a whole.

The most valuable feature is the Fail-to-Network (FTN) option, which means that if for any reason the appliance goes down then there is no interruption in traffic.

It allows for easy categorization of data according to the hostname, out of the box. For example, we may not want to unencrypt certain things that are subject to compliance, such as an e-commerce site, government site, or a banking site. We can easily detect and classify these, acting accordingly once they have been classified. In a single click, I am able to specify which category of hostnames it should decrypt or not decrypt. This allows us to easily comply with enterprise policy.

It is easy to bypass decryption not just by category but also by using the IP address. For instance, we have a finance minister who sits in our network and we do not want to see their internal activity. This solution allows us to bypass that traffic based on IP, whether it is the source or destination. We can also bypass decryption based on the URL.

Technical support needs to be improved.

I would like to see a graphical trace or view of the issues. It has to be in the simplest language because a lot of network and security operations people do not understand SSL. For the sake of smooth operations, there should be a graphical, easy naming convention for SSL. The GUI should give us easier access to those concerns, like a packet tracer. If somebody enters the host IP or the hostname then it will tell the administrator that there is a problem with a policy, or what is causing the issue. Again, it has to be in the simplest words because not all organizations can hire PKI experts. It depends on the organization because in banking they will have a PKI team and they understand these things well, but a lot of organizations do not have the same resources. Essentially, from an operations perspective, they have to come up with nice ways for operational personnel to easily and effectively manage it.

We deployed the Symantec SSL Visibility Appliance in our data center about six months ago.

So far, we haven't experienced any stability-related issues in terms of hardware or software. So far, so good. As long as you understand the way it behaves, the way it works, and the way it processes traffic, then one should not expect a lot of issues with the product itself. It is a vast subject and one needs to understand it very well, but once it is deployed it is reliable and it can really deliver what you had expected before making the decision to purchase.

Scalability depends on the model that you purchase. We have an SV2800 or SV3200 and we can deploy it as a standalone box or in HA mode. Depending on the model that you purchase, there is a limitation in the number of network modules or Netmods. This is something that should be done as part of the initial assessment and determination of the host requirements. If you find that five Netmods are sufficient then the initial requirements will be met and only if you have new network zones, you have to bring in new devices.

It really all depends upon the type of deployment. I could have multiple zones that connect to it, and there is a choice between active interception versus passive. There are lots of options and many factors. Overall, it is scalable and you can add as many as you want because it is not a legacy HA device, where there is a limit of 24 or 30 devices, or where you cannot have a cluster size with, for example, more than 20 or 30 devices. There is no such limitation.

We have approximately 7,000 employees who are covered by this solution. We do plan to increase our usage by including more business applications. We're going to have our DLP solutions in place and we have big plans for our SOC security team.

These days, I have not been happy with technical support. The issues are not related to the SSL but rather the proxy. The justification from the vendor is that due to the acquisition of Broadcom, the service has been impacted.

Overall, I would say that for the past two months, we have not been satisfied with the level of support that we have been getting.

This is the first SSL visibility product that we have used.

The implementation is very easy and it is a same-day deployment. The majority of the time spent on this solution is only after users report an issue. There are, of course, network requirements and passive requirements that have to be in place before starting, but that cannot be counted in terms of implementing the solution itself.

I implemented this solution with the help of our partner company.

In terms of maintenance, I am the primary point of contact, but we do have an operations team that handles operational-level activities. For instance, if there is a need to bypass one of the hostnames then that request goes to the operations team. If there is an issue that they are not able to handle then I will jump in to address it.

This solution provides a good return on investment. The hardware is very good and they are already prepared to decrypt SSL 1.3. Of course, not all types of traffic can be decrypted, but it is something amazing that most other vendors cannot do.

Licensing fees are billed annually and we purchased a three-year license. Five-year licenses are also available.

I did some research on other products and found that with F5, for example, you could not whitelist which sites to intercept and which ones to ignore.

We did see that there were other solutions on the market but we did not evaluate or compare them.

Most of the customers who maintain their own data center will use the on-premises deployment, but there are cloud-based SSL solutions as well.

My advice to anybody who is implementing this solution is that there is nothing like a full-fledged HA deployment and when it comes to SSLV, one should always go for active-active deployment. Also, until somebody understands SSL and PKI very well, they should not try to implement this product. If it is not properly implemented then the support team, or operations team, will be very busy.

During the planning phase, you really have to understand what is inside the web proxies that are in place. For example, you need to know what exceptions have been entered for each of the servers, each of the clients, and each of the hosts. Based on all of that, they have to make sure that they are implementing SSLV correctly.

The biggest lesson that I have learned from using this solution is that you shouldn't go into operation until you transparently test everything. You don't have to go live immediately. I would suggest that you keep SSL bypassed and monitor how many messages are failing or are not being processed correctly. We had to do monitoring for at least a month and kept a constant eye on that. This will give you a clear idea of how many issues you're going to have to face. By doing this, you have the option to correct the problems immediately. If not, and you go into production, you will have a really hard time and may have to roll back.

I made this mistake, where I did not monitor everything for a couple of days. I just did some quick tests like a few categories and a few URLs, then said that everything was working fine. There was the pressure of compliance during this time, so I had to put the system into production. It was good for three days and then the problems started. Had I done the monitoring and kept a constant eye on the log, understanding each and every log message, then I could have avoided these problems.

I would rate this solution a seven out of ten.