What is our primary use case?
We use it to secure the internet connection of all of our users, ensuring that they can connect as transparently as possible to all of the websites that are, of course, not hazardous. And anything hazardous is prevented as much as possible.
How has it helped my organization?
We were looking for an isolation solution so that there would be no impact at all on the systems that we are responsible for protecting. We didn't want to wait until a first attack was successful and then find out what the impact was and how we should react to it. That's why we chose Menlo. Either you have access to something or don't have access to it. And if you do, we can ensure, 100 percent of the time, that there is nothing malicious that is going to impact our system in any way. And that's for the on-prem users who are connected to the corporate offices, as well as for the users who are roaming.
The primary benefit is that it secures users wherever they are, whether they are roaming, or they are using their PC at home, at work, or at the airport. We are able to do that, and we are even able to do it with companies that we recently acquired.
Another move forward was that we started inspecting SSL traffic, which was something we were not inspecting before. We were closing our eyes to what was happening to 98 percent of the traffic because it was encrypted. Today, we are not closing our eyes. Menlo enabled us to inspect more traffic and avoid relying on traffic that clearly can be hazardous. That may be one of the reasons we discovered new use cases that were difficult to test before, and for which we have had issues configuring Menlo to handle.
Another advantage is the ability to produce reports that help us to understand what our users are doing, even within the website. For example, are they posting files or are they downloading files? That is clearly an ability that we acquired with the solution as well.
And when it comes to isolation, we haven't seen any threats that have succeeded in coming in through Menlo. I have evidence, of course, that in some cases we were infected by malware, but it was not able to avoid Menlo's protection and connect back to the internet to get instructions from the command and control service. We have clearly demonstrated that those threats just cannot harm us.
What is most valuable?
The isolation is one of the most valuable features.
The fact that it is a cloud proxy solution is another feature we like. For example, if you acquire a new company, you can use it to protect that new company without the need to install anything physically on their networks.
Also, the ability to rewrite the links in emails so that nobody can connect to a link without going through Menlo's protection is something we have found very valuable.
And the reporting feature, which involves a kind of programming language to query the logs or the data from the Menlo console is something we consider to be quite useful.
What needs improvement?
The solution should have no impact but it does have a bit of impact on end-users. For example, we encountered some issues in the downloads that took longer than they did without using Menlo. That is clearly not transparent for users. We expected not to have any latency when downloading anything from the internet with Menlo compared to without Menlo.
We are now transitioning to another solution. The main reason for that is that managing all of the exceptions and troubleshooting all of the issues our users have had connecting to the internet has become too significant in terms of workload, compared to what we hope we will have with another solution. In other words, we hope to get the same level of protection, while reducing the number of visible bugs, issues, latencies, impacts on performance, et cetera, that we have today with Menlo. We already solved most of them, but we still have too many such instances of issues with Menlo, even though it is protecting us for sure.
The weak point of the solution is that it has consumed far too much of my team's time, taking them away from operations and projects and design. It took far too much time to implement it and get rid of all of the live issues that we encountered when our users started using the solution. The good point is that I'm sure it is protecting us and it's probably protecting us more than any other solution, which is something I appreciate a lot as a CISO.
But on the other hand, the number of issues reported by the users, and the amount of time that has been necessary for either my team or the infrastructure team to spend diagnosing, troubleshooting, and fixing the issues that we had with the solution was too much. And that doesn't include the need to still use our previous solution, Blue Coat, that we have kept active so that whatever is not compatible or doesn't work with Menlo, can be handled by that other solution. It is far too demanding in terms of effort and workload and even cost, at the end of the day. That is why we decided to transition to another solution.
If we had known in the beginning that we would not be able to get rid of Blue Coat, we probably would not have chosen Menlo because we were planning to replace Blue Coat with something that was at least able to do the same and more. We discovered that it was able to do more but it was not able to replace it, which is an issue.
It is not only a matter of cost but is also a matter of not being able to reduce the number of partners that you have to deal with.
In addition, they could enhance the ability to troubleshoot. Whenever a connection going through Menlo fails for any reason, being able to troubleshoot what the configuration of Menlo should be to allow it through would help, as would knowing what level of additional risk we would be taking with that configuration.
For how long have I used the solution?
We have been using Menlo Security Secure Web Gateway for two years.
What do I think about the stability of the solution?
Now, the stability is quite good. I would rate it an eight out of 10.
What do I think about the scalability of the solution?
We have it deployed worldwide, in about 300 locations.
In the case where we acquired a new company with a significant number of systems, the ability to deploy Menlo to all of them, even if we were talking about 40,000 people, would not be an issue at all.
One thing which could be a real issue is the ability of the solution, within the development plan of Menlo, to fit our needs. This is what led to our decision to remove Menlo.
Which solution did I use previously and why did I switch?
We were using Blue Coat Systems before. First, that was clearly not protecting users who were at home or roaming. Second, it was not possible to use it to protect companies that we acquired until they confirmed that they were going to implement Blue Coat appliances on their networks. So Menlo was a huge move forward.
How was the initial setup?
The initial setup was complex from the beginning, and even once it was in operation. We even needed to have an on-prem meeting with my team in charge of the implementation and the techs from Menlo to determine the best configuration settings to make it work and avoid issues as much as possible (which we still had afterward). It is not at all simple to deploy.
We had between five and 10 people involved in the setup. They were in charge of operations, meaning any changes to or troubleshooting on equipment that was live. Others were in charge of the implementation of this type of system, including defining the proper architecture and configuration and adapting and tuning the configuration.
A couple of years later, we still had a significant number of open tickets with their help desk due to issues connecting through Menlo.
It is deployed on the cloud. We were planning to use Menlo on-prem in China, but we are rerouting the traffic from China to Hong Kong and going from Hong Kong to the internet.
The maintenace is not lightweight. I don't know what portion of the time that we were spending on the tool was due to maintenance and what part was due to new issues that were raised by our users. The maintenance is a split responsibility between the local IT operational guys and the people from my team.
What about the implementation team?
Our experience with their consultants was very good.
Our only issue is that we kept asking them how they managed, with their other customers, the issues we were encountering. An area for improvement for them would be that when they meet their customers, don't let them think that they're troubleshooting something for the first time. There is no reason that they wouldn't have seen something different with another customer.
They were not leveraging the experience they had with other customers enough to anticipate and prevent the issues on our networks; or, at least, when they happened, to solve them much quicker than they would have if they had never been seen before. We consider that as a lack. They need to learn how to let other customers benefit from the experience they had with us.
What was our ROI?
We haven't seen a decrease in the number of security alerts that our security ops team has to follow up on, but we were not even able to measure that before deploying Menlo. It's very hard to demonstrate the return on investment by looking at the decrease in the number of incidents compared to before, as we had nothing before that was truly able to demonstrate to us what was really happening.
If we had implemented a solution from a Menlo competitor before, and we were moving to Menlo, that would have enabled us to compare both solutions. That is something we are going to do after we transition from Menlo to Skyhigh Security, even though the alerts will not, of course, have occurred at the same time. We will be comparing things that are a couple of months, or years, apart. We will try to demonstrate the different levels of protection provided by Menlo compared to Skyhigh. But that will happen half a year from now.
What's my experience with pricing, setup cost, and licensing?
The pricing is good. We were convinced that it was the right price for such a solution at that time. Again, we didn't know that we would have to keep Blue Coat. At that time, we were thinking that we would be able to get rid of Blue Coat, and for that reason, the price would be good.
Which other solutions did I evaluate?
We evaluated several other solutions, including Zscaler and the complete portfolio of Symantec as well.
We went with Menlo because of the connection to the execs of Menlo and the ability to talk to them. The size of the company, compared to Symantec, was definitely a factor, but the ability to get in touch with the right people as quickly as possible, and trust their strategy and their level of protection, were important. The ability to get a contract where they commit to protecting, 100 percent, against any threat, as long as you use isolation, was a clear improvement for us. And the fact that it was a cloud proxy solution, was another part of the decision.
What other advice do I have?
My advice is to pay attention to all of the use cases you have and try to understand what Menlo is or isn't addressing so that you don't discover that you still need to keep an old technology that may even be outdated. To do that, you need to be very clear about your use cases and how you will cover them with Menlo or if Menlo will not cover them.
While the solution provides a single console for security policy and management, which is an interesting feature, as long as you're able to connect through APIs to all your SaaS solutions, the fact that you use the very same SaaS solution or not is probably less important. I'm not saying it is not important that Menlo has a console, but it's a bit less important if you're using an orchestration automation solution. We also have Palo Alto Cortex XSOAR that we are using to automate and orchestrate.
Regarding the fact that Menlo secures the web, email, SaaS, and private applications, the latter, private applications, is very important, as is email although probably less so. The magnitude of risk is higher for private applications that are exposed without protection on internet. It depends on the use cases that you are looking to cover. If, for example, you don't have any private applications that you need to expose, then of course that type of protection is not important at all, but you still receive emails within which you need to rewrite the links. If you have both requirements, meaning a bunch of private applications that are exposed plus emails for which you need to rewrite links, in that case, rewriting the links is probably less important than ensuring the protection of your private applications.
It doesn't make sense to only perform partial protection. Everything you implement to secure the connections and the assets you are responsible for should, at some point, merge together. It should be SD-WAN and web gateways and probably even CASBs and email protection. All of that probably will tend to merge together and you can look forward to reducing costs and the number of partners.
Don't look at it as: "I have a new need, I want a new solution," because if you do that, you will end up with a huge number of vendors and solutions on your systems and it's going to be super difficult to ensure that you manage all of that consistently. Whereas if you really have a vendor that is at least addressing, if not all the possible needs, at least all of your needs, and you are able to manage that in a consistent way, even if you have to program something in your orchestration solution, you will be able to manage all of it in a consistent way and in a timely manner.