The user monitoring could still be improved. We are a government agency, so we purchased Menlo by user. If we have 3,000 users, we need to see that all 3,000 users are able to use Menlo. However, there aren't any reports that say, "In the past six months, all 3,000 users have logged in," because there are some cases where SSL is bypassed, for example. When they access sites like that, the user is not tagged as a normal user, so 3,000 may become 2,900, but I still need to account for 100 users. I'm working with Menlo right now to make sure that all user activity will be visible to me.
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.
Right now, the only piece would be one or two reports that I'd love to get my hands on. I don't think they exist. With any system firewall or solution like this, you have to create bypasses, which is an access control list. One of the standard things that we would do in other firewalls is a regular review. We quarterly go and take a look at who we grant access to and if it is still needed. For example, when you're working with a partner, you might do a full bypass to that site as long as they are a partner, but over time, you add 200 extra rules. At some point, that partner you had ends up no longer being a partner, but that old rule is still there. You want to be safe. You need to give them access today, but you don't necessarily need to do that tomorrow. So, you need to be safe about it and block it again. Currently, I don't have a good way to see which of my rules are being used in the access control lists. I have numerous entries, but are they all still needed? A report that would show me my list of who is allowed and whether we're actually using it would be useful because I can then go clean up my list. It would be easier to manage. We would eliminate the vulnerability of unused services.
In the best of all worlds, we wouldn't have to make any exceptions. However, that is a big ask because a lot of that depends on how websites are constructed. For example, there are some very complex, application-oriented sites that we end up making exceptions for. It is really not that big an issue for us to make the exceptions. We feel like we are doing that without a huge impact on our security posture, but we do have to make some exceptions for complex sites, e.g., mostly SaaS-type sites and applications.
Menlo Security Secure Application Access
Menlo Security Secure Application Access makes zero trust access easy, giving users secure connectivity to private applications, including web and legacy applications. At the core of Secure Application Access is the Menlo Secure Cloud Browser, which fetches, secures and delivers the content for users.
In addition to providing simple-to-deploy, clientless ZTA, Secure Application Access and the Menlo Secure Cloud Browser protect applications from...
The user monitoring could still be improved. We are a government agency, so we purchased Menlo by user. If we have 3,000 users, we need to see that all 3,000 users are able to use Menlo. However, there aren't any reports that say, "In the past six months, all 3,000 users have logged in," because there are some cases where SSL is bypassed, for example. When they access sites like that, the user is not tagged as a normal user, so 3,000 may become 2,900, but I still need to account for 100 users. I'm working with Menlo right now to make sure that all user activity will be visible to me.
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.
Right now, the only piece would be one or two reports that I'd love to get my hands on. I don't think they exist. With any system firewall or solution like this, you have to create bypasses, which is an access control list. One of the standard things that we would do in other firewalls is a regular review. We quarterly go and take a look at who we grant access to and if it is still needed. For example, when you're working with a partner, you might do a full bypass to that site as long as they are a partner, but over time, you add 200 extra rules. At some point, that partner you had ends up no longer being a partner, but that old rule is still there. You want to be safe. You need to give them access today, but you don't necessarily need to do that tomorrow. So, you need to be safe about it and block it again. Currently, I don't have a good way to see which of my rules are being used in the access control lists. I have numerous entries, but are they all still needed? A report that would show me my list of who is allowed and whether we're actually using it would be useful because I can then go clean up my list. It would be easier to manage. We would eliminate the vulnerability of unused services.
In the best of all worlds, we wouldn't have to make any exceptions. However, that is a big ask because a lot of that depends on how websites are constructed. For example, there are some very complex, application-oriented sites that we end up making exceptions for. It is really not that big an issue for us to make the exceptions. We feel like we are doing that without a huge impact on our security posture, but we do have to make some exceptions for complex sites, e.g., mostly SaaS-type sites and applications.