What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using Bitglass for about a year and two months.
What do I think about the stability of the solution?
The solution's overall uptime is top-notch, 100 percent. We've had zero outages related to the product.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
Which solution did I use previously and why did I switch?
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.
- The agentless reverse proxy.
- We are moving to zero trust.
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.
How was the initial setup?
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.
What about the implementation team?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
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.