Code42 Incydr Reviews

When I first became acquainted with Code42, we were implementing it at an employer I worked with, and that was a successful implementation. I now work for a consulting firm, and we do system implementations of a variety of different DLP tools, and Code42 is one of them. I still use it, but it is for the benefit of my clients, as opposed to the company I work for.

The pedigree of Code42 came from a toolset called CrashPlan. So, CrashPlan predated Code42's product, and it was mainly in helping organizations prepare for disaster recovery and business continuity planning in significant server environments. We use it in three main areas. The primary area that we use it in is in providing identity into data loss prevention and data loss protection in terms of:

• Where is that unstructured data?
• Who has access to it?
• How did they come to be authorized to use it?

It is a broad-based area of use, and then the other area of use is discovery. Many of our clients engage either with their staff in legal battles, or some other thing, where they need to perform discovery. We support discovery with Code42 as well.

Its deployment was on-premises, and that just happened to be the ecosystem that we chose to work from. It is still going fine, but I don't think it would matter one way or another. From our standpoint, it was fine. Ultimately, we'll probably move to the cloud, but at that time, we were looking for on-premises.

It is an enterprise system, so it can be used in a medium size to large size company, but the thing that we look for is data loss prevention. That's critical for us. The ability to protect against intellectual property theft, the overall insider threat prevention, and then data exfiltration is valuable to us. Many of our clients are concerned about data being exfiltrated from their organization, unbeknownst to them. That's an area around which we create visibility.

There are a couple of things. One of them is that they have what they call Incydr. Their detection and response solution to the insider threat area is called Incydr. That gives visibility to the clients that have widely dispersed employee bases due to work from home, or that had a dispersed workforce predating any of the work from home requirements. Even though they might not be inside the organization physically, they're inside the organization. It allows us to get some visibility into what people are doing, what the context is, and how to control what might be the potential for intellectual property theft or file exposure.

In a couple of instances, we had a little bit of trouble in getting it distributed throughout the organization. We ultimately managed to do it, but they talk about it being a pretty simple process, and it became a little laborious. It would just turn away. The agents were not being distributed. It was just churning and churning and churning. When we were looking for specific categories of data, it was getting bogged down, but that was not even so much Code42, although some of it was their issue. It really has to do with the overall infrastructure and what the organization is prepared to do. If the infrastructure or the networking is a little hinky or you don't have a really finely tuned network infrastructure environment and your patches aren't up to date on your servers and your endpoints, it could get a little sticky. Other than that, it was okay. We really didn't have much problem beyond that. It took a couple of days to sort that out, but it was no big deal.

It goes back to around 2018. It has been about four and a half years.

We didn't have any issues. We bolstered our network incredibly. There is a lot of stuff running through our pipes. So, we now have a pretty strong network. We didn't initially, but we now have a really strong network and pipe environment. I don't really see any problem with it. The only problems we have are not related to Code42. They're related to the fact that we have to make sure that, at times, the people who work from home leave their technology available for us to do updates, to do scans, and things like that, but that's not a Code42 issue. That's more of an internal issue.

It is an enterprise system. It can be used in a medium size to large size company. It is very scalable. We took small numbers within departments, nailed that, and then moved on to different departments and nailed that. It scaled pretty easily. I don't recall anything going off the rails.

It is being used throughout every department such as IT, human resources, marketing, sales, HR, finance and accounting, legal, and operations. There are 16,000 people in the company. So, it pretty much is going to touch everybody. There are two primary locations: one in Northeast, Ohio, and one in New York, but then there are literally thousands of locations across the United States. People are working from home. They're all over the United States. We had an operation in Canada, but we didn't do anything overseas.

We don't really talk to them much. We talk to them from time to time about the potentiality of moving to a different infrastructure environment, but that's about it.

Their customer service is a solid eight out of ten. There are always going to be hiccups. Sometimes, you put in a call, and you'd like to get a response sooner than later, but nobody is perfect. We don't expect anybody to be perfect, but we're happy with it, especially in comparison to some of the other vendors we work with. They're light years ahead of everybody else. They got a good team. The people that you talk to, they're not just reading off of scripts somewhere, walking you through. They're doing a decent job. They know the product.

Positive

We didn't use a particular service in an enterprise environment. We used different environments. We used some of the earlier renditions of Microsoft in terms of its compliance manager tool set. We also used another tool, which was primarily an e-discovery tool that we leveraged into utilization, like a DLP system. There was another tool called InfoGPS, which was really good for financial areas and banking, but beyond that, it really wasn't a good fit.

The primary benefit that we saw was the company itself. They had an advisory team that could help us in terms of onboarding it in terms of where to look and in terms of supporting different technology platforms. They were able to give us some insights into training. They had a pretty decent Insider Risk Management Training program. Security awareness fits into that as well. We could target the training for different client requirements, which was pretty nice.

You really have to understand your network environment going into it. You can't second guess it. You have to provide them with as much information as you can about your bandwidth, the server environment, the number of users, and where those users are located. A lot of those things needed to be right-sized, which just wasn't done upfront.

In a couple of instances, we had a little bit of trouble in getting it distributed throughout the organization. We ultimately managed to do it, and that was a little hickey, but we didn't have a problem otherwise.

In terms of the implementation strategy, we had a four-phase approach. We called it the four Ds. The first was Discovery. So, we had to go through a discovery process to determine things like:

• What is the key functionality?
• What are we looking for?
• What areas of solutions do we want it to fit in? 

We then had to discover what companies might be out there. We went through an analysis of companies. We did discovery.

The second phase was when we made a decision to work with Code42. We sat down, and we did a design session. We created an architectural design at a high level, and we talked about the outcomes that we're looking for from the standpoint of:

• Policy
• Technology
• User profile
• Acceptability
• Ease of use

We had all that designed in, and then we did the actual development. We developed all the charts. We used the standard waterfall project management implementation strategies or incorporated SDLC. We did all the things you would do for standard project management, such as critical path, key stakeholders, etc. All that was done in the development phase. That's when we actually onboarded the technology on our server environment. We then worked up a test scenario and did deployment, which was the fourth D. We did deployment on a group-by-group basis. We didn't do a big bang or everybody at once deployment. We took a subset of users from a department, and we implemented it in a department. We went to another department, and we implemented it in that department. We scaled all the way through. The first department we worked with was security. We implemented it within our own security team, and then in IT in general. So, we did security, IT, marketing and sales, HR, finance and administration, and then overall operations was the way we implemented it.

They had an advisory team to help us in onboarding it. We got the consulting support. We had an individual come out. I don't know what his exact title was, but he was a senior consultant who had done multiple implementations in the past and was familiar with the product. He wasn't a junior guy by any stretch of the imagination. He knew the information he needed and he knew how to work with us. He was a pretty reasonable guy. He was around the first couple of weeks. He came on site for a week, and then after that, he came in every once in a while for about three months. By then, we had already done most of the heavy lifting, and we were into full-scale development and implementation. We would talk to him all the time, but he didn't come on-site anymore. I would rate him a five out of five. We thought he was really good. He was capable, and he was knowledgeable. He had a great personality. He wasn't high-minded or anything like that. He was a good guy to work with. In fact, he's still around today.

For the deployment, on the security team, I was the overall leader. I didn't work on it full time, but I was the overall leader of it. Then I had a security analyst from my team on it, and I had a security service engineer on it pretty much full time. As supplementary, I'd have a junior guy or a network analyst help out from time to time, but there were really about three people who worked on it throughout. There was also a project manager, but he was from the project management team, not from our team.

In terms of maintenance, there is a regular tuning. We pay for the software maintenance. There is software maintenance, but we tune it. Like everybody else, there is regular care and checkups to make sure that everything is running properly. If we see anything that's running amiss, or if we do a heavy patch load, sometimes, we'll pay closer attention to what's going on at the endpoint because of the patch load. It is not cumbersome for sure. Its maintenance is handled by the network admin. A security architect is also there from time to time, but it is mainly done by the network administrator. He may dish that out to one of his support people, but by and large, that's all that's involved. We haven't had to call Code42 for anything that we couldn't figure out.

We have absolutely seen an ROI. We found a lot of value in being able to detect the file sharing and potential exfiltration or actual exfiltration. Not everything is done maliciously. Sometimes, people just do it, but it is not done maliciously. They might embed a PowerPoint thinking they're embedding a PowerPoint pie chart in a presentation, but they're actually embedding the entire spreadsheet. We were able to detect that. 

The other thing that it has helped us with is that it showed us where we had gaps in our security policies and acceptable use policies. It showed us how to measure the effectiveness of a policy. That was pretty strong, and we really liked that.

It was expensive. It was more expensive than Eureka, and it was more expensive than Barracuda Backup, but what we got was a full team. They didn't come in and nickel and dime us. They provided the assistance we needed. They didn't say that they need to charge us for something or it is going to take another statement of work. It was all bundled into it. The organizations that can't afford or are not interested in an enterprise solution, such as a medium-sized business, they're probably not going to want to spend the money, but you get all the maintenance. We got the training. We got the consulting support, and we got the advice and console. We had an individual come out. He really didn't need to, but he came out on-site and worked with us. So, it was pretty good.

You could certainly add on different functionality. You could buy extra consulting, and you could buy other services. We chose not to do that, and it worked out okay for us. At the time I was involved in the purchase, they had a bundled solution, or you could buy it a la carte. I don't know what they're doing in 2022, but it probably still is the same. It was, at least, through the end of last year.

We pay for the software maintenance. It is probably 18% or 20% of the license fee for rev releases.

InfoGPS was evaluated. There were a couple of other tools that were evaluated. It really got down to the fact that as an organization, Code42 had the features we were looking for. They offered a tried-and-true product. One that had come from a long pedigree. They understood the whole realm of data security and privacy. They had data and security privacy experts on staff, which were pretty good. That was very helpful.

The other tool that we evaluated was from Barracuda. It was primarily around the Barracuda backups. It was called Barracuda Backup Live or something like that. It was pretty cool, but it was limited in terms of the feature set that we were looking for. We did a proof of concept, and it took us longer to get that up to speed than Code42.

The very first thing you should do is make sure that you know exactly what you're looking for. There's a whole bunch of stuff out there. Data loss prevention or data loss protection is a big category. It can cover a lot of ground, but you have to make sure that you know what you want, and you have to prioritize that list. We call it a value-based prioritized roadmap. You have to know what you want and what's critical for you at that point in time. Don't try and do everything all at once. Give yourself the top three things that you want to accomplish within a certain timeframe and work toward those. Spend your time on those. Don't get off track because it is easy to get off track with new features and all that. You should just stick to the plan and work it through. So, definitely make sure that you have a priority list of what functionality and what services you're actually interested in.

I would rate it a solid ten out of ten. We've been very happy with it. It covers a lot of space and is very scalable. They have good people to work with. It is a little pricey, but you get what you pay for. We find it a pretty straightforward application to work with. We've been able to leverage it to help improve our policies. It is a good tool.