The Symantec SSL Visibility Appliance is a high-performance transparent proxy for Secure Socket Layer (SSL) network communications. You install the SSL Visibility Appliance in the network and attach one or more security devices to it. The SSL Visibility Appliance is able to decrypt the SSL traffic, enabling the attached security appliances to see the plaintext (that is, the original unencrypted data) in SSL encrypted connections. It eliminates the blind spot created by encrypted traffic, enables your organization to combat the threats hidden within SSL, while preserving user privacy and regulatory compliance. Powerful policies allow you to bypass specific types of traffic (such as financial or healthcare data) to maintain employee data privacy.
We are a federal organization and we are classified as number four in terms of sensitivity. That was enough for us to think about mitigating the blind spots in the traffic. We have to offer an SSL solution that could enable the rest of our analytics solution. We brought SSLV to start dictating the traffic. We actually wanted to efficiently utilize our security solution with a threat detection solution.
This was something we were lacking, our FireEye did not have the ability to see the SSL traffic because FireEye was very late to release their SSL offloading functions. They were really late and they relied on F5 Orchestration and we did not want to go with it. So we got SSLV. Since we brought a system, we also started feeding the created traffic to analytics that also enhanced our detection rates and our proxy. That proxy is also benefiting from that. We are able to categorize and detect a lot of URLs, hostnames, and file types.
One of the most valuable aspects of this solution is that it's easy to deploy without a lot of complications. Of course, one has to be very good at understanding the PKI as a whole. But in terms of implementation, we are utilizing Fail-to-Network, which means even if SSLV for some reason goes down, we don't get traffic interruption.
In terms of SSLV's feature itself, it is very flexible in terms of whitelisting. For example, if I do not want to encrypt some things that are subject to compliance, it has easy categorization of the hostname that is out of the box. In one click I am able to dictate which hostname it should encrypt or not. It is easy to abide by the compliance policy. It is not just category-based, it is also very easy to whitelist or bypass the decryption based on IP addresses. For example, we have a finance minister who is in our network and we do not want to see all of his internet activity. It allows us to bypass it based on his IP address.
There are many ways we can bypass SSL decryption. Be it destination IP, the source IP, the URL, the hostname, et cetera. This is the easiest solution and I did a little bit of research before and I could not find another solution that does this.
There is also a return on investment. They have very good hardware and it is already prepaid for SSL 1.3. They have a way to do that. Not all types of versions can be decrypted. But to some extent, they can do that also, SSL 1.3. That is something amazing and most of the other vendors cannot do that.
We have been using Symantec SSL Visibility Appliance for around six months.
So far we haven't experienced any stability related issues in terms of the hardware or software. So far good. As long as we understand the way it behaves, the way it works, the way it processes the traffic then we don't expect a lot of issues with the product itself. It is reliable and it can really deliver what we were excepting before we chose it.
Scalability depends on the model that you're purchasing. We have got 2800-B or 3200-B. We could deploy it as a standalone box or in an HA.
It all depends on the type of deployment. I could have multiple zones connected to SSLV. It depends on how the organization wants to have an active interception of SSL traffic or if they want traffic.
I would say that it is scalable. You cannot have a cluster size with more than 20 to 30 devices. One is going to get as many devices as they want to and go on deploying it.
The bottom line is there is nothing like a full-fledged HA deployment when it comes to SSLV, so one should always go for active-active deployment.
We do have plans to increase its usage, we are going to use it for our business applications also.
The issues we've experienced haven't been related to SSLV but actually with their proxy solution. The vendor says our problems are due to the acquisition of Broadcom and they were going through a transition period and that's why the service product has been impacted. We haven't been satisfied with their support for around two months now.
We had a look at F5 Orchestrator and that is it.
It was a one day deployment. It was me, my supervisor and our partner company. I was responsible for its successful deployment.
The operations team handles the operational level activities. If there is an issue that they are unable to handle, I will jump in and address it. My primary responsibility is to handle the project.
We have 7,000 employees using the solution.
Don't go for this solution until you understand SSL very well. If it's not properly implemented, the operations team will be busy with the installation. Especially for the service that requires software updates. For the planning phase, you have the first wave to understand what is inside the web proxies.
Keep a system bypass. Monitor how many of the accessor positions are failing or unable to process clearly. We have to have a monitoring period for at least a month and keep a constant eye on it. That will give you a clear idea of how many issues you're going to have. If I just keep the action blocked for the SSL connections, that are not labeled terminated, then I can take action immediately. If I failed to do so and if I go directly to the correction I will have a really hard time. I have to actually rollback. I have done this mistake. I did not monitor everything for a couple of days. I did quicksteps to fill categories, a few URLs and I said everything was working fine, there was operational compliance. I had it rolled out. The moment it rolled out it was good for the first three days and then the servers infra team started calling us saying that the updates were not operating.
That is the biggest lesson. One should give time for the monitoring and assign each and every logged message.
In the next release, I would like to have a graphical view of the issues. Something in a simple language because a lot of network security operations do not understand. For the sake of smooth operations there should be a graphical, easy naming convention of SSL and it should also give us easier access. From the operations perspective, they have to come up with easier ways so that the operational guys can easily manage it.
I would rate it a seven out of ten.
