It was basically for an EDR solution. We were apparently in the migration phase, to be frank. We were using McAfee VSE, and we wanted a media solution which would give us more insight in terms of the events that are happening with respect to Malware threats. So that's the reason why we went for the Carbon Black Defense.
It has improved the number of alerts or the number of threat events that we are able to recognize in our environment. And it also highlights the usage of potentially unwanted programs. So these are the ways in which that highlighted the possible vectors through which we can have an incident happening in our environment. That is one thing that we have seen.
In addition, the detection ratio compared to that of a typical anti-virus and the EDR solution or the next gen AV as they call it, is on the ratio of one to ten when you compare it with a Symantec Endpoint Protection, McAfee AVR, or VirusScan Enterprise versus Carbon Black Defense.
Carbon Black Defense has a higher detection ratio because it's cloud-based and it also does a lookup to virus total, so it is out of like 65 vendors that are normally listed in virus total, if there are any kind of hits out of those, in that case, it is getting recognized as a known Malware or a suspected Malware. Under these categorizations, we are able to see a spike in the detection ratio. It is enlightening us with respect to what are the programs that are generally used in our environment and how they are compliant with our environment.
It is still evolving, as we see. We started using the version 3.0. We've been migrating and upgrading as well, laterally, until version 3.2. So, we have been seeing a lot of improvements in general in terms of bug fixes and in terms of what are the things that we had encountered.
I think they can probably bring in because there is a little bit of a gap between the native Antivirus solutions like Symantec or McAfee. So, you really can't say whether an end user will not be able to judge whether it's a Malware-free software that they are downloading or not. In those cases, if you have an application and a device control feature, I think it would be of great help.
We had some issues with the stability. In regards to the driver file, and the CTI files, there were some issues. In addition, there were a couple of issues with servers and the workstations. It was an intermittent issue, and not widespread. But it was basically because the current organization I'm working with, we created a lot of in-house applications. They don't go very much hand-in-hand with Carbon Black enabled. They have certain behaviors, like they inject code into themselves, which is a design that they have. Even the Microsoft authorized or licensed tools exhibit such kind of a behavior. And these behaviors are being identified as a malicious behavior.
I think it would be better if they can have an application database, where if these kind of applications are performing this, you can bypass, or you can overlook them. Something like that would be helpful. Otherwise, we will have to manually bypass them or allow them logs, as per the policy configuration for these applications. It takes a little bit of an extra time in terms of developing a new tool in the in-house application, as concerned.
I would say, not really. But we have a, how to say, our hands are tied down in terms of generating reports to understand or analyze the trend or anything of that sort. Because when you look at the EPO, you will be able to do certain trend analysis on the basis of the data that is already available in the database. But ,we can hardly take any kind of a report out of Carbon Black, so I think that should be something that should be more user-friendly. They are asking us to use API's, and not everybody is well-versed with API's or scripting.
They also do have a limitation on that, in terms of pulling out the raw data of events. The event generation is like a 1:10 ratio like I said. That detection is also on the same base. So if you have to pull out a report for an end-point count of, say, 35,000 to 40,000 endpoints, the events will be on the higher side. So, the limitation is set to 5,000, which is not realistic.
Tech support with Carbon Black is a current point of contact in the tech support. So whatever it is we interact with a single point of contact. And more of a liaison where he can bring in people from the developer side, or the account manager, or the technical manager, or whatever it is. We can get them into loop. That's the kind of the support level that we have subscribed. We don't reach out to the normal tech support by call-dialing into a number. They are responsive. We have really not tried off-business hours out of US time zones. I think that causes a little bit of a challenge because we are not able to catch hold of the right person at the right time in case of any kind of outages or something like that.
The service response is pretty much satisfactory. But if you look into a 24-7 support, then you might have to wait in the morning. I'm located in India, so if we have to look into reaching out to a person in the US during the Indian business hours, in that case, it's night. So, we will not be able to reach our support person. So we might have to rely on calling someone during that time. But we normally don't do that. Until now, we have not got any kind of an issue where we really have to contact tech support during the off-business hours. Because we do have our US counterpart, so we work on that particular region timings so that we can involve Carbon Black support to get the maximum out of them.
We did a comparison of products and analyzed how many of them are getting detected on a weekly basis. We also did a trend chart for a monthly threat review. Which basically was with McAfee VSE and Carbon Black. And we thought, that is the reason why it was like one is to ten over a week or a monthly trend.
I was part of the initial set up. We were doing a comparison with FireEye HX and other tools, as far as CrowdStrike ,Avira and Carbon Black. We chose Carbon Black, and I was part of the initial setup. And since we don't have an in-house setup, we have a cloud-based console, we don't have a dedicated server set up. It's much easier to implement with a cloud-base. So the resource requirement is much lesser in terms of the hardware is concerned.
I think it took somewhere around four to six weeks of time. We had the implementation done and then we were into the testing phase by doing UT testing and stuff like that, internally with a closed group. And then we moved on to selected groups and users who might be important in terms of revenue generation, and stuff internally, so we did that. And then we moved on to the global deployment. I think, over a period of time, I would say the initial implementation was done with a maximum of four to six weeks. And then, I think within six months of time, we actually had the complete deployment done.
It was pretty straightforward. The console was easy to understand because we have had complex consoles with EPO. This was a pretty straightforward console. And the user guide basically gave us the information about what we can do and what is available. Though it can still be more extravagant in terms of describing itself. But, it just gives you the right information in a short and sweet fashion.
They're still evolving. I think they should reach there in a couple of years, I would say. I'm not really sure what is their roadmap, so that is one thing that I can say. But that should be something that would come up as an add-on or something like that which can be purchased or which can be given as a free component as well. I'm really not sure, but I think they might think in these lines, to bring about a better security control with the Carbon Black AV, to be specific.
I think the only advice that I would like to give is you need to really test it on different platforms. That's the only advice I can give you, because if you have a versatile environment, such as ours, while we do create a lot of in-house applications, we need to have an extensive testing done so that we don't end up creating a roadblock for other teams who are into software development and software testing. And those kind of lines. That might create a lot of issues with Carbon Black. If you test it prior, then probably you would have a better idea as to what you're getting into. And implementing it would be even more easier in that case. I think we did the right thing in terms of that because we know our environment better. If you know your environment better, you would do the right thing.
I just told you the price point that's one of the factors, basically because that is what the higher management gave us as an input. But, we didn't play a major role in terms of deciding. That was done by another person from the organization. So, that was just a communication that we received. So, that's how much I know about it.
We also had a review of FireEye HX as well, but we chose this in terms of the utility and also in terms of the cost involved. So that is the reason why we chose CB Defense. And, so, that's the reason why we are currently using CB Defense. We wanted to have an insight about Malware, the vectors for which they come into and what kind of a behavior they exhibit. So these are the things that we are basically looking to the Carbon Black Defense.
I think they can probably bring in because there is a little bit of a gap between the native Antivirus solutions like Symantec or McAfee. McAfee does have a separate product, the application control. And Symantec Endpoint has the application and device control as a built-in component in 11, 12, and I think in 14 it has the same. But the EDR solutions currently don't have that kind of a feature. So, if they can incorporate that, it would be a better security control and an antivirus, basically, because you do have instances where Malwares are getting into the network through an RFD or through a particular free software that users might download from the internet.
In terms of the fixes from what the behavior was with the environment, it has been evolving. And the only thing that could be improved is enabling Carbon Black to be a part of the image so that when we are doing a image refresh, Carbon Black would be present by default. But in the current conditions, by definition, it needs to have an internet connection for you to install Carbon Black. Because it connects to the cloud as a first step after you start the installation. So, since we cannot have that kind of a set up for an image, we are not able to put it into an image, basically. So if there comes any kind of a version where it can be done, probably it might be more helpful in terms of a mass deployment.
They might have to create a little bit of better knowledge base articles which will give us an insight as to how this is working and what logs we can look into for analysis. The gap can be made much shorter in that aspect. The report generation and trend analysis or data analysis can be improved.
it describe a good experience