It's our CASB, our cloud access service broker. It also does our SaaS-based based DLP, our data loss prevention, for our SaaS-based applications. We use it to protect our sensitive information. Since we are a healthcare corporation, we have to do everything we can to keep PHI data from leaking outside of the organization.
It's a SaaS offering, but there is an online appliance, a VM server, for the Active Directory sync back to the SaaS.
We have our own data centers, multiple data centers, and we always had the philosophy in the past that we're always on-prem in our data centers, never in the cloud. All of a sudden, one day, somebody had an epiphany and realized that we could save money by closing most of our data centers and putting things into the cloud. We wouldn't have to worry about buying infrastructure and all the hardware. So all of a sudden our company had this mass push to start sending everything possible to the cloud. But as the security department we looked at that and said, "Hang on. There's a lot of sensitive data in all of this that causes a HIPAA compliance issue and a PCI compliance issue. How can we protect that?" That is the number-one way that Bitglass helped us; with our stuff going to the cloud.
Another aspect is that we recently went from an on-prem Exchange environment for email to the cloud-based email. What we did not really understand at the time, because it was on-prem and we didn't worry about it so much, was that we have a lot of PHI data inside of our email environment; more than we ever even thought imaginable. With Bitglass, we're able to inspect every single email sent. And if we see that it's going outside of the organization, we can stop it, unless that person has the authorization. We'll have special policies written for that person or that group of people to allow that to happen. We've never had those controls before in the past where we could stop PHI data from leaving the organization.
As for the AJAX-VM providing constant reverse proxy uptime, out of the year and two months, I can't tell you that Bitglass has ever been offline. And that is a tremendous value because of something that we've never had in the past: Any employee in the company who has access to a staff-based application could go home to their grandmother's computer, or to their mother's or their own personal computer, and log in to those SaaS-based applications and download social security numbers and patient records. Now, with the reverse proxy, we can stop that. They can try all they want, but the reverse proxy can stop it dead in its tracks. We've hardly had issues with the reverse proxy uptime. If we have had an issue, it's never been around Bitglass itself, it's always been some kind of on-prem issue. For example, we had some switches that were doing port flapping and it took us three days to figure out that it was not Bitglass. It was actually the switches that were causing all the on-prem issues that were being experienced.
In addition, we haven't seen any latency. With some applications, there might be a few milliseconds, but nothing really noticeable at all.
They have an agentless reverse proxy, which is amazing. They also have an agent forward proxy, which is very helpful. That's how you can identify the company-managed devices. With SaaS-based applications, people want to be able to access their email, for example, from a personal computer. The reverse proxy allows us to protect that and keeps them from downloading PHI data to their personal computer. But once we see that it's a company-owned device, because it's a forward proxy, the agent solution enables us to relax the policies a bit and allow them to actually do their job and access the sensitive information, if they're allowed to. That's a huge piece.
We install the forward proxy on a machine and we can have it inspect the machine for certain criteria that would classify it as a company-owned and protected device. For example, we can make sure that it has antivirus, an EDR solution installed, disk encryption, and things like that. That way we know they didn't take this agent and install it on their personal machine and that this is definitely a company owned device. With that solution, we can send them through what's called the forward proxy, which allows us to open it up to do their job, and they can access sensitive information.
What's helpful about the other piece, the reverse proxy, is we can still allow them to access their email or other SaaS-based applications if we want. But, if they go to a personal device and do so, it will put them in reverse proxy and still forward proxy because it's agentless. That will allow us to identify this is a personal device and that we have to lock the policies down so they don't download sensitive information which is not allowed to be on a personal device that is not protected with company controls.
I also find the granular level of inspection that you can do inside of all the proxy traffic to be very useful.
In terms of how the solution secures us against data breaches and attacks, it works alongside an IDP solution that we have. We use Ping and they integrate together, so we can force multifactor authentication. And even if someone makes it past the multifactor authentication and login for Ping, if Bitglass doesn't have the proper SAML tokens passed to it through the SAML insertion, it will not allow access to those sensitive applications. Let's say someone were somehow able to hack someone's credentials and hack multifactor authentication. That's a tall order. But at the same time, Bitglass will be able to take a unique login that happened somewhere else — for example, the user is here in Tennessee, but now you have a login 500 miles away or 300 miles away, as well. Bitglass will be able to detect that and stop it because it's an invalid login. It knows that it's suspicious.
The solution is very good when it comes to securing us against data leakage, because of the other proxy. It also has API scanning or data at rest. It inspects data in motion, which is the proxy, and then it has the data at rest, which is the API scanning. We can inspect for anything we want: file fingerprinting, PHI-sensitive data, PCI-sensitive data. It does not matter. We can usually find it and block it in transit and do our remediation with it. It could either be block, encrypt, or allow and watermark the file to follow it and see where it goes. It allows for those different scenarios.
I wish they would advance more into the endpoint DLP solution. Currently they do not do anything around endpoint, they're still strictly cloud-based. The forward proxy is really the only thing they do. What I would like to see them do is to scan machines, workstations and servers, for information we might not want on those machines. That would be huge. We have to consider the fact that that's not really their arena, but I think if they would come into that arena, they would open themselves to providing a more complete solution.
I have been using Bitglass for about a year and two months.
The solution's overall uptime is top-notch, 100 percent. We've had zero outages related to the product.
The scalability is outstanding.
One thing that we did find — and this is where we made mistakes in our deployment — is that instead of doing our Direct App Access and doing 10 users in reverse proxy and forward proxy and then 10 more in just reverse proxy as a test, we started rolling it out department by department, facility by facility, in big waves. We have about 100,000 employees. We were going to roll to all those employees in just seven waves. We made it to wave four before we had to stop our deployment. We found that Bitglass itself would automatically scale and just handle it. They always talked about their infrastructure and how it auto-scales based on demand. What we would have is about 20,000-plus users logging in between at 8:00 am and 8:05 am Central Time, which was a ton of traffic all of a sudden slamming at the infrastructure, and it just handled it like a champ. It would scale.
There's still room to grow. I have to stress, it's not Bitglass' fault. It's a company strategy. We have to figure out what our strategy and what our DLP program and cloud-based program is going to be.
In the applications that we have put into it, there is a 100 percent adoption rate, but we're still in the discovery phase of trying to find out how many SaaS-based applications are in our organization. We're at well over 100 SaaS-based applications. Over the last six months we've been vetting all of those applications and meeting with the teams that run a given application in the cloud and with the teams that use it in our enterprise. We're starting a number of such applications each week, finding out the details: What does it do? Does it support the infrastructure that it takes to integrate with Bitglass? We've been working on that for six months.
I have used their support quite a bit. They are outstanding. I've been able to call them at any time that I'm here working. It doesn't matter when, they've always been very responsive. If I don't get somebody when I call, usually within five to 10 minutes, max, someone's calling me back.
In addition, if we run into something that we don't like, and we say, "Okay, this thing could be better," they open up an enhancement request and they'll take it before their board and they have a discussion about that feature request. If they need clarity, they will actually get their engineers on the phone with us to get more clarity on what we're actually asking for. I would say that they've implemented more than half of the things that we've requested. They're very open to improving their product for the users. Those improvements are available to all customers.
They'll do some things for independent customers. For example, even though we're an Active Directory shop, we have an IDM solution called NetIQ. It's the source of truth for all user accounts. It propagates out to AD and controls what's in AD. It controls what's in all the different types of applications. Bitglass supports AD integration, but didn't support our IDM solution, which is essentially just LDAP. What Bitglass did, on the fly, was that they created their agent to adapt to our IDM solution. They will actually do specific stuff for a company, but when it comes to the overall product itself, they make sure that changes are going to benefit all customers.
The whole Bitglass package, which is a single solution, encompasses CASB, web security, advanced threat protection, identity, DLP, and zero trust network access. As a company, we're moving towards zero trust. Two things made us, as a company, choose Bitglass.
We liked the way their product looked compared to the competitors. We liked the fact that it has an agentless solution, which is the reverse proxy. That allowed us to protect our data without having to worry about blocking the users. The thing that's important is that our people still need to access their email, for example. If they're on their personal device, that's fine, we want them to have that access on their phones, etc. But what we don't want is patient data on their personal devices, and that's what the reverse proxy is predominantly about.
The initial setup was straightforward. It was one of the most simple, easy solutions I've ever seen, in terms of setting it up, given that it's such a predominant piece of cloud security and zero trust. It's almost out-of-the-box. It just works. It's crazy how easy it is.
We're actually still deploying. In Bitglass' defense, because we are so young as a company in going to the cloud, we've had a lot to learn ourselves as far as SaaS-based security and DLP programs go. We've never had either one of those. We're still trying to figure out exactly where we are. Unfortunately, and it's not Bitglass' fault, we are currently deploying, again, in our enterprise. We are actively deploying as we speak.
Our deployment strategy is different today than it was in the beginning. As an organization, in the beginning, we wanted to understand things more and we took our time and made a lot of mistakes. That was not Bitglass' fault. Our deployment strategy now, which is what I recommend to everybody, is to understand all the apps that you are going to deploy Bitglass for. Make sure you understand the capabilities of the application and what the application contains data-wise, because realistically, all applications might not need to be in Bitglass. That's a company choice.
When you deploy Bitglass, what I have learned is that you deploy what's called Direct App Access. When Bitglass receives the login information, it says, "Oh, we're going to send this user directly to the application and we are not going to send it through any kind of proxy." For example, if you go to gmail.com to log into email, it's not going to send you through the proxy, it will send you directly to gmail.com. What you do is you take about 10 users, depending on the size of your organization, and you put their company-owned devices into forward proxy and you have those same users use a reverse proxy away from the company. Then, you take another 10 users and you put them only in reverse proxy. You don't write any policies to restrict any kind of access in any of the proxies. You then watch how that works and make sure that there are no unknown issues with proxies with those SaaS-based applications or APIs. It doesn't matter what solution you use, when you deal with a proxy — this is something we've learned, it doesn't matter what proxy you deal with, whether it's Bitglass or some kind of proxy server — there's always the chance of issues.
I'm the only super-admin. We have about 40 additional role admins who have view-only access to investigate issues with people being able to log in. That is all they can do. As far as administrating the app configurations, I'm the sole person.
We mainly deployed it ourselves. That comes back to what I was saying. If we had listened to Bitglass, they could have helped us through the deployment process a little bit better. They wanted to be involved, they offered their services, time in and time out. But again, as an organization, we were wanting to understand everything better. It's our own fault that it's taken so long to deploy.
We haven't seen a direct monetary return, but we have seen an indirect monetary return. We pay however much the licensing is for Bitglass every year, and that is a cost we didn't have in the past. However, the HIPAA fines, and HIPAA compliance issues — the millions of dollars that we could be liable for if patient records are leaked outside of the company — create an indirect return on investment.
Their pricing is extremely fair.
They need to make sure they pay attention to how the licensing works. There are many licensing methods. One way is the number of endpoint users you will have. And they license for every single application that you're going to put into the proxy system. They also have a few other types of licensing around CSPM, so there are many components.
Bitglass didn't misrepresent their licensing structure in any way, but as a company we didn't really look at what it meant. Fortunately, we feel we got a really good deal with Bitglass and we got everything we need. We didn't have to go back and buy any additional licensing. However, if we had not just blindly gotten the right deal, we might have needed to go back and revisit the licensing structure with our account manager. We really didn't fully understand the way all the licensing worked until after the fact. Do your due diligence and make sure you understand. Don't over-buy your license and don't under-buy.
We never really deployed anything else as vastly as we have deployed Bitglass. We went into the PoC phase with several products. Bitglass is the one that has continued to stand out in performance and ease of deployment. It's simple to use. I hate to even say this, but it's very elementary. They put a lot of time and thought into the interface to make it as simple as it can be.
We looked at Symantec and we PoC'd McAfee and Proofpoint. In terms of the differences between these solutions and Bitglass, the first thing is the ease of deployment. Then there is the agentless reverse proxy, which no one else had, and the ease of use. And performance was another difference. What we found with some of the other products was that they were very resource intensive. Some of them also required a lot of on-prem appliances, whether VMs or other things. Bitglass was the only solution that was totally cloud. The only reason we have anything on-prem is because we're an Active Directory shop and have to feed the users up to the cloud. Otherwise, Bitglass does have the capability of being a 100 percent cloud solution, because it does have its own IAM service.
My advice is to listen to Bitglass when they tell you how to deploy it properly. That's one of the two main things I have learned from using this solution.
The other is, when you deploy this, always — and I stress this greatly — always deploy the new app or new API in what's called Direct App Access. That means once the user is authenticated into Bitglass, regardless of whether it's an external IDP or you're using the simple, built-in IDP from Bitglass, Direct App Access sends you directly to whatever it is you're trying to access, with no proxy. Always deploy with that, and then select about 10 users for reverse proxy, as well as 10 users that will use reverse and forward proxy. I would recommend that those 20 users be power users, people who use those applications on a regular basis. Bitglass is pretty seamless and it integrates well. But if it's an application that it has never integrated with before, which a lot of our applications have been, there is always the possibility that Bitglass is going to have to make a change for that application. That is a lesson learned for us. We would take an application that they had never integrated with before and we would just slam all of the users into it. It could handle the scale; it scaled fine. But what would happen is that there are certain JavaScripts on the client-side that Bitglass wouldn't handle correctly. It's not a fault of Bitglass, it's just a difference in technology in the way that the product was developed.
So we identify that there's a problem with those power users. We then take those users out of the proxies and allow it to stand Direct App Access. When you do it that way you don't have issues. They can investigate, they can figure out what the issue is, they address it, and they fix it. And then you can start easing the deployment out again. That's huge.
The solution provides a single policy page to secure all of our interactions to the cloud, but not for on-prem. It's not really much of an on-prem solution. There are ways that you could do that, with firewalls. But Bitglass is really more of a cloud-based protection and it's not meant for on-prem devices. With that being said, there is a single policy page around Bitglass, but when it comes to each SaaS-based application or API, then each one of those has its single page of policy. So you have your policies for Bitglass itself, then you have your policies for each app or each API. Bitglass's approach which, for me, makes a lot of sense, is that every application is different. So it's hard to treat them all the same.
We don't yet use the solution's SmartEdge Secure Web Gateway. We are currently in the process of talks for bringing that into our environment. I find a lot of appeal to it and there are a lot of things with that new SmartEdge that would be extremely beneficial to our organization.
Overall, knowing what I know now, a year and two months later, and having been through this whole Bitglass deployment with the issues that we've had that were not Bitglass' fault, I would still choose the same product today. I would do it again, but I would listen to Bitglass more and I would change my deployment method.
MCAS was onboarded for the purpose of detecting shadow IT. As the organization moved towards more SaaS solutions, we wanted to make sure that there is a way to monitor and govern the IT services coming up as shadow IT. We are a very big organization where a lot of services get onboarded, and some of the things may go unnoticed. We wanted to detect the shadow IT software being installed or shadow IT happening within a department or business unit.
We also wanted to make sure that the cloud access security broker provides a DLP kind of solution for Office 365. For example, if I am uploading a document with PI data, MCAS should scan and make sure that the right classification is applied. When the right classification is applied, the document gets encrypted, and relevant information protection is applied. If the right classification is not applied, the users are alerted to make sure that they go and remediate the document, task, file, etc.
This is how we started with this solution the last year. Going forward, as a strategic solution, we are also looking at using MCAS to govern the Office environment. We have started onboarding solutions like Microsoft Teams, SharePoint Online, OneDrive, and Exchange Online.
Our setup is a mixture of on-premises and cloud solutions. At this point in time, the major cloud providers are AWS and Azure, and we also have on-premises products such as Symantec DLP, Doc Scan, etc.
There are certain regulatory requirements in our bank for personal data and confidential information that need to be monitored from a security standpoint. It is a regulatory and standard requirement to have such a solution in place.
MCAS is a dedicated solution for Office 365 and other productivity-related solutions, and it really helps to automate some of the processes. It would have been difficult for us to find a similar product. It gels well with some of the solutions or technologies that we have, especially with Microsoft Azure and Office 365.
From a security monitoring perspective, there is a productivity improvement and fewer human errors.
In terms of user experience, if users mistakenly put PI information or some kind of data, it can detect and alert them. From that aspect, it is doing the job, but we are using it from a security standpoint. I'm more from a regulatory environment, and there are security requirements that are enforced by regulators. So, we cannot provide some of the end-user experience features, and there should always be a balance between the end-user experience and the security standpoint. MCAS is more of a backend security posture product. I won't position it as enhancing the user experience.
The feature that helps us in detecting the sensitive information being shared has been very useful. In addition, the feature that allows MCAS to apply policies with SharePoint, Teams, and OneDrive is being used predominantly.
It is a kind of unified solution. As compared to other solutions such as Netskope, Symantec, or McAfee, it provides a more unified reporting structure.
It also integrates with other technologies. We have Azure Information Protection, and it goes well with the solutions that we are already using.
It takes some time to scan and apply the policies when there is some sensitive information. After it applies the policies, it works, but there is a delay. This is something for which we are working with Microsoft.
It cannot detect all the things that are required as per our bank's standards. We are working with Microsoft to see how they are going to help us resolve this, and based on NDA, which new features are coming in because we require a unified solution. We have other security solutions that are working on top of it, but we don't want to use multiple solutions and then end up with a human error. From a security perspective, the weakest link is human error. If certain features are monitored by MCAS, certain features are handled by Zscaler, and certain features are handled by Symantec DLP, it becomes difficult to synchronize from an operational standpoint. This is the situation we are in currently, but these issues come with new products or new cloud solutions. We have to slowly orchestrate and see how to unify the solutions. So, at present, it doesn't solve all the problems. There are many problems, but at least, we have other solutions that are currently providing some mitigation.
It doesn't provide any way to scan Microsoft Teams when an external exchange of images is happening. You can always do the filtering on the documents during the chat, but if there is an image, then some kind of OCR capability is required to detect it. At present, there is no way MCAS can go and detect those kinds of images and alert us. They can maybe integrate it with an existing OCR-capable product. This is something that we are absolutely looking into. There should also be a feature to immediately increase the time to detect some PI information being exchanged via chat.
Its reporting capabilities can be better. Currently, to generate reports, you need to have Power Automate in place. If such capabilities are built into the product, it would be easier because when we bring in Power Automate, we need to make sure that Power Automate also gets monitored from the DLP and governance standpoints. MCAS doesn't have many reporting capabilities, and it's really an operational nightmare to get all these things done at this point in time by using MCAS. These are some of the operational capabilities that our engineers require from this solution from the reporting perspective. Symantec and other solutions are more mature in this area. It could be because MCAS is still an upcoming product.
We onboarded Office 365 and cloud services less than two years ago. MCAS was one of the strategic and DLP kind of solutions for Office 365 and other productivity products. Because the onboarding of the cloud services is in phases and not everything can be onboarded at the same time and it requires the involvement of different security and project departments, MCAS was onboarded last year.
From an enterprise perspective, it meets most of the interoperability requirements. So, scalability is there. I don't see an issue from the scalability perspective. Only features are missing here and there.
Currently, it is almost serving the entire bank. In terms of the SaaS products that MCAS is monitoring and the number of users it is serving, we have onboarded around 40,000 users for Office 365 and other SaaS products. Eventually, it will be serving the entire bank, but at this point in time, it is only serving all Office 365 and SaaS product users.
It is more of a cybersecurity solution for the bank to comply with all the security requirements and meet the security quotient. The end users don't see MCAS as a direct solution, but MCAS is providing security services for the bank behind all the services.
We have proper help desk support. For example, if someone uploads a document that has PI data and there is an issue, it is highlighted to the user asking them to remediate it. The manager is also copied. The help desk takes care of such things.
Once the solution is implemented, it is almost auto-run. From the support perspective, it is mostly about why did I get this alert, what was wrong with this document, etc. Such things are usually taken care of by the user because users are responsible for what content they are allowed to load on a particular website, SharePoint site, or software. A robust change management process and help desk are already in place, and I don't see a big concern on this aspect.
Previously, we didn't have any cloud product. We only had on-premise products. Our organization joined the cloud around one and a half years ago mainly because of this pandemic situation.
It depends on the requirements. Certain requirements are really complex. The deployment itself is quite fast because MCAS is on the cloud, but there are a lot of requirements from the regulations and the bank's standards perspective.
It took us one week for the architecture and to decide things like whether we need a reverse proxy. To have all the requirements and get all the things done in an enterprise environment, typically, a simple product like MCAS can take three to six months. That's because there are a lot of governance requirements, and we need to make sure there is no PI data, and the keys are encrypted somewhere in the user ID part.
In terms of the implementation strategy, at the high level, for Office 365 and SaaS solutions, we wanted a unified product to replace our existing one. From the strategy perspective, we wanted to go to the cloud. MCAS was able to integrate with most of our Office productivity tools. We procured the licenses and then went through the strategy of the bank and how the product can meet the needs. This was at a very high level. Of course, when we go into operations, we get operational challenges. That's why we need to have a longer time period to make a product coexist with the existing products.
We have our own department, and they are trained in it. We also engage all sorts of vendors to provide us the results. At least for the interiors, we do not engage a third-party reseller or contractor.
It was more of an in-house implementation, but Microsoft helped us in coming up with a service design for Azure-related products including Office 365. Based on our requirements and infrastructure, they provided high-level architecture and design documents and told us about the things to be included or considered. We took that service design document and built our operations based on that and got it to work. So, the service design came from Microsoft, but hands-on was by our bank.
In terms of maintenance, this is actually managed by security folks and cybersecurity services. Currently, it is being managed by three people. There are only three operators. Of course, when there are new things to be implemented and new policies to be created, it goes to engineering. For changes, we need one more person on average. So, there are a total of four people.
I can't give a specific number. One of the returns on investment is that we will soon be getting rid of our on-premise infrastructure and maintenance. The CapEx costs and repeated hardware refresh cycle are gone. From that perspective, there are savings. All we need is the skill set to maintain and manage a particular cloud access security broker. Today, we have four people, and tomorrow, it could be eight people because of the increase in the number of applications. The bottom line is that we will get rid of all operational issues in terms of patching and fixing different systems. We don't have to patch the Windows systems, Linux systems, etc. All these are taken care of and are maintained in the cloud.
I'm not totally involved in the pricing part, but I think its pricing is quite aggressive, and its price is quite similar to Netskope.
Netskope has separate licensing fees or additional charges if you want to monitor certain SaaS services, whereas, with MCAS, you get 5,000 applications with their Office 365. It is all bundled, and there's no cost for using that. You only have the operational costs. In the country I am in, it is a bit difficult to get people with the required skill sets.
I have been here for just around one year. When I came, they were already using MCAS. In my previous organization, I made the decision to use MCAS for Office 365. For the entire cloud, I decided to use a dedicated cloud access broker like Cisco. It really depends on the organizational requirement and how they want to size their IT department.
There are pros and cons. If you are totally on Microsoft products, MCAS has an integration. Otherwise, there are other products that may work better. Of course, you may still be dependent on some APIs from the cloud providers. It really depends on the organization's strategy.
My advice would be that an organization should assess where they are today and then map out what do they want from a cloud access security broker product. After that, they should decide whether MCAS or another product meets their requirements. This is important because you may have all the things in terms of interoperability and a solution may be the best fit from an operational perspective, but if all of the requirements are not met, you may end up using multiple products. Therefore, an organization must assess its current IT infrastructure, where do they want to go, and what are the key requirements from a regulatory and IT governance standpoint. They also have to make sure they have the right skillset in the market. For example, in Singapore, if I want to implement Google Cloud, the skillset is very less as compared to the skillset for AWS.
From a vendor perspective, you should assess the reputability of the vendor and what kind of capability the vendor provides. For example, it's very obvious that Microsoft is very good at integrating its own products. They have now also started to integrate with others. These are some of the aspects you should consider before making a decision between product A or B. There is no magic silver bullet.
From a security standpoint, overall, it has satisfied 80% of our requirements in terms of regulatory and bank standards. For 20% of our requirements, we still need additional products or features. They are currently not really there, and we are trying to find the solution for those gaps. In general, MCAS has a long way to go. It is definitely a good product that integrates with Office 365 Suite very well, but from a capability perspective, other products such as SkyHigh, McAfee, or Symantec have more features. It has the potential. A lot of features are lined up in MCAS, and eventually, they'll be there. These features are mentioned on Microsoft's website, and they are in development. I am looking forward to those.
In terms of data governance, we have a very good tool, and we just need to focus on how to govern the data, DLP policies, etc. We don't have to bother about the physical data center, physical network, or physical host. The entire layer below the server is gone, and we just have to focus on the identity and security aspects. We just need to focus on what kind of security we need to put and which policies do we need to implement. We get better visibility by focusing on the key client endpoints by using MCAS. The team is now really focused. Previously, every day, teams used to come up with issues like, "Network has this problem. Data has this problem, and Host has this problem." Now the focus is, "Hey, this MCAS DLP isn't doing the job." The focus is more on the product's capability.
I would rate Microsoft Cloud App Security a seven out of 10.
We have two main use cases. The first one is for APIs only. We have the APIs connected to this console, and they include the API from Facebook Workspaces, and also Google.
The other use case is for URL filtering using an agent of Netskope.
The agent is the easiest to deploy. Once it's deployed, it easy to enable features such as URL filtering, et cetera.
The interface is good.
The onboarding process is pretty straightforward.
The configuration is okay.
There' lots of great new features.
It's one of the best solutions on the market.
The way that policies or profiles are set up can be adjusted. You have to create a list of policies and then you need to reorder everything if you want to adjust the way that the policy is applied to traffic. In some cases, when you have a lot of policies, it can get confusing for users and you can get lost in the GUI. Maybe they can improve on how to order everything.
In the short term, the solution really doesn't need to add any other features.
I've been using the solution for about a year or so now. It hasn't been that long.
At this time, after about one year of use, I have heard that there were a few issues, however, it's been minimal. For the most part, it is stable.
I haven't witnessed any issues with scalability. It seems that it would be possible to scale.
At the moment, most of our users are engineers and then we have 19 to 25 users at the bottom, and people from a few different departments including administration, finance, and IT.
We do not plan to increase usage at this time, at least, in terms of users.
We haven't had any issues and therefore have never really had a need to reach out to technical support. I can't speak to how helpful or responsive they are overall.
We didn't previously use any other solution.
The initial setup was okay The deployment we handled was small. It only took us about two weeks to get everything up and running.
At this time, two people are in charge of deployment and maintenance.
I don't have any information about the licensing. It's not an aspect of the solution I really deal with.
We did take a look at McAfee before choosing this solution.
We also looked at Bitglass, however, there wasn't really an evaluation process that went into effect. We just took a quick look.
We looked at the infrastructure and how the solutions could control latency between users and applications.
We are both a partner and a high-end user.
We are always using the latest version of the solution, as it updates automatically. The console is running on a Netskope site. From there, a user can deploy agents to a computer or servers on-prem or on the cloud, however, it's not the console itself. It's the agent's server that is forwarded to the cloud.
It's important to look at the solution to see how it will work for your company, A solution might have a good user interface, a beautiful console, and nice graphics, however, you really need to look deeper to see if it fits your organization's needs.
I'd rate the solution nine out of ten. It's been very useful for us so far.
