I would advise understanding how your workflows go because with users being remote and on-prem, you probably have to come up with some type of a hybrid solution. If you're trying to provide protection for your workforce, you'll wind up with a hybrid solution. I'd give it a nine out of 10. It is hard for me to give something a 10. It is a really good product, and I don't have any problems with it.
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.
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.
I would advise understanding how your workflows go because with users being remote and on-prem, you probably have to come up with some type of a hybrid solution. If you're trying to provide protection for your workforce, you'll wind up with a hybrid solution. I'd give it a nine out of 10. It is hard for me to give something a 10. It is a really good product, and I don't have any problems with it.
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.
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.