Vectra AI Reviews

We use it as our internal network monitoring solution.

It's interesting to consider how it has helped our organization because it's a security product. But the way it has helped is that nothing has gone wrong. And it has certainly enhanced our internal security capabilities.

Vectra has helped accelerate our threat investigations, providing us with real-time visibility of potential threats to the network that we can act upon or triage accordingly. Prior to the implementation of Vectra, we didn't have that visibility. We had a number of disparate security tools, each with its own alerting functionality. Vectra has significantly helped with a consolidated view of potential threats. And the prioritization of threats allows us to focus specifically on those threats that we believe present the greatest risk and to react to those threats extremely quickly.

Vectra MDR is also very important for us, given the relatively small size of our internal team, and it gives us 24/7 capability that we didn't have before we used Vectra's MDR service.

We particularly like the user experience around the dashboard, which we find to be much more straightforward than the dashboard of some of the competitive products. In the grand scheme of things, we're a relatively small organization with approximately 1,000 users and a small internal security team. Compared with some of its competitors, Vectra is a really easy system to understand and use to prioritize where we need to focus our security resources.

We use Microsoft 365 and Vectra extends our ability to track attacker activity, whether that happens on-premises, in a data center, or in a SaaS environment. It provides complete coverage and visibility across our ICT estate. That was a real positive when we were going through the selection process. The simplicity of the dashboard and the categorization of alerts as low, medium, high, or critical, presents us with the potential of a security risk. We can then choose to investigate it, regardless of whether it's an on-premises or cloud-security risk. They are presented in the single-pane-of-glass dashboard, and that allows us to take the appropriate action. The detection and prioritization of attacker behaviors are extremely important.

A blind spot that I have is around the ease with which you can automate threat intervention.

We've been using Vectra AI for approximately 12 months.

It seems to be extremely stable. We've not had any issues in that respect.

Vectra has visibility across our entire ICT network, which is a combination of on-premises and cloud environments. Our cloud solution is Azure, and it extends to about 1,000 users. The vast majority of them are now remote or mobile workers.

It has comfortably managed the needs of our organization and I don't have any concerns if we were to need, at some point in the future, to either scale or switch the current balance between on-prem and cloud.

We are very satisfied with the support. It has been excellent so far. It has been very timely, very personalized, and always quick to find solutions. We've been really pleased with it.

Positive

We didn't have a previous solution. We have no internal networking monitoring capability.

We started with a proof of concept and then we committed to the Vectra solution. That's when we began the formal implementation. From the very initial engagement to the proof concept and through the transition to service, it took approximately six months.

The deployment went very well and that was a real positive in terms of the engagement with the onboarding and the customer experience.

Across our ICT team, six individuals were involved in security, infrastructure, project management, and service transition.

There is no maintenance of the solution on our side.

The implementation was supported directly by Vectra UK itself.

The return on investment from the product comes from not incurring unplanned costs because of a security incident.

The upfront pricing model that we have would have been more beneficial if it had been a recurring license fee, but that wasn't a massive issue for us. It's fairly priced.

We evaluated other options very thoroughly. It became a two-horse race between Vectra and Darktrace. The differentiators for us were the UI experience, the MDR, and we felt that there was better engagement with the Vectra presales team. They better understood our needs and how Vectra would fit as a solution.

The percentage of critical alerts from Vectra that are critical or true positives, to be fair, is relatively small, probably about 10 percent, but that's more a reflection of the fact that we're still a relatively new client and that the system is still learning. What we have noticed though is that the triage process is effective and we don't get multiple false negatives once we've identified an issue.

We bought Vectra AI through our IT partner, which is CDW. They were only involved in the procurement process. We used a partner to ensure that we could demonstrate that we had done so according to compliance.

I would definitely recommend Vectra and to do a proof of concept. We learned quite a lot through that proof-of-concept process. Those lessons certainly helped us when we went into the implementation process and to engage internal ICT team stakeholders and anticipate central issues in the implementation process. A proof of concept would be invaluable for anybody thinking about implementing this or one of the competitive solutions.

At the moment, we're really pleased with the product and it's a really good fit for the size of our organization.

We use Vectra AI for endpoints where we are unable to install agents, like endpoint agents, EDR agents, or antivirus tools. For example, BYOD devices or routers in our network. We don't have any control over those, but we need monitoring capability. 

Vectra AI can monitor the traffic from the wireless router to the firewall or any outgoing traffic. It can give us an idea of whether there is any C&C or C2 communication or any botnet activity from those source IPs. Without having any agents in the endpoint, it is a network monitoring tool. We use this tool to detect threats within the environment where the assets are unmanaged. 

Also, since we tap into certain network points such as firewalls or IDSs, we get more visibility from managed assets as well. So before the endpoint notices the behavior, Vectra notices some of the exfiltration techniques and alerts us.

Overall, it is good and has reduced our time in identifying the system. It is for unmanaged devices. Previously, if we got an alert from the firewall, it was very difficult to find that particular asset. But with the help of this tool, we can simply run a packet capture and immediately get the hostname and know which user is using it. 

It has greatly reduced our time to remediate the situation. We can identify the user, block their account immediately, and sometimes kick that device off the network completely.

It has a confidence level of around 60% to detect insider threats of anomalies, but we mostly need to fine-tune the product. We are still in the fine-tuning process. Even though it has been one year since we implemented the product, the first six months were spent integrating various log servers and determining where to tap. 

For the past three months, we have been actively investigating the alerts. When we investigate some of the insider alerts, most of the time it is a false positive because the domain is allowed. Vectra does not know that those are allowed domains, such as OneDrive and SharePoint, to access our network devices. 

It considers it malicious because a huge amount of file uploads is seen, according to Vectra. But we know those are known URLs and known behavior. When we slowly started whitelisting, the threat confidence level increased. So right now, for insider threats, it gives around 60% confidence, but around 80% of the incidents were false positives because we are still in the fine-tuning process.

The packet capturing feature is very useful, and as the name suggests, AI uses models to detect abnormal behavior. Some of the patent-matching algorithms they use are very advanced and detect threats at a very early stage.

For me, detections from unmanaged networks are one of the greatest values. You can identify threats from BYOD or even mobile devices, which were not handled before.

The detection algorithms can be improved at the sensor level rather than doing all the things at the brain. For example, if the sensor has some directional algorithm or detects repeating traffic, it can drop those packets at the beginning itself. There is no need to send that traffic to the brain in order to reduce the bandwidth.

AI is picking up a lot now. There is no manual intervention needed. Whenever a detection happens, it can automatically summarize and give it to you. But Vectra doesn't have those kinds of capabilities. It still needs manual intervention to analyze, and they don't have a summarized kind of output. So that can be improved. But apart from that, the detection models and all the other categories have good support for that.

In future releases, I would like to see Vectra AI to generate a summary of the instance.

I have been using it for a year. 

I would rate it at eight. The remaining two points I'm not giving because it's a fairly new product. So far, it is good as per our test and it is able to scale as well.

The only limit is you need to increase the sensors when you have more traffic. For example, the current sensors can handle up to 50 GBPS of traffic per second. If you need more traffic to be utilized, then you need to buy additional sensors to handle the traffic.

From a technical perspective, there is not much more possible, because there are some hard limits in the hardware. You cannot increase the bandwidth. They have other options to increase with more sensors, but it ultimately ends up being a cost factor.

If you have more money, you can buy more sensors and do it.

In our organization, we are an MSSP provider. We use Vectra, and our entire SOC team, which is around 20 people, uses Vectra for our MSSP. We have two customers who are also using this product. Two of the largest telecom industries in Thailand are using this product to understand their behavior as of now. The approximate number of users in those categories will be around ten.

The customer service and support are good. So far, we have not faced any issues at all.

The setup is a very straightforward process. You need to tap the network traffic at your desired point, and it has two components: a sensor and a brain. The sensor collects the logs and forwards them to the brain, which does the detection and everything. They offer a virtual appliance that you can run in your environment. 

The setup process is usually very simple. It took only two days to set up. But, initially, deciding the location of the sensor and other factors took more time. The threat team at Vectra AI engaged with us effectively, provided all the support, understood our architecture and advised us on placing the sensors.

The licensing is on annual basis. 

I would rate it at nine out of ten. The one point I'm reducing is because the model can learn itself. If no one is fine-tuning it, for example, every time we find a huge number of alerts, then only we go and look it up and fine-tune the product. 

If no one is acknowledging it or it seems like regular traffic, then the product can understand that behavior and have a feedback mechanism to correct it, mark it as a false positive, or whitelist it.

My recommendation: 

Understand your network first, and place the sensors in the correct position to receive all kinds of traffic: THC, PDNS, and all those things. If you place the sensors at the egress traffic, you may not receive some of the packets, and you will not have overall visibility. 

So the placement of sensors is very important; you need to understand your network to place them correctly.

Our Customers use Vectra AI to detect networks, endpoints, identities, SaaS-based, and private and public clouds.

The most valuable feature of the solution is that it only shows us the events that are actually critical. The solution is currently used as a central threat detection and response system. It ingests every bit of information from the SIEM, does AI triaging and detection, and sends incredibly high-fidelity alerts to the SIEM for investigation.

It would be commercially beneficial if Vectra AI had something like Darktrace's Antigena Email or something similar to email protection. 

I have been assisting customers using Vectra AI for nine months.

Vectra AI provides 100% stability because it sends you either a physical box or a VMware deployment, making it very simple and stable. Obviously, VMware will depend on your own environment.

Vectra AI is a scalable solution. Since we have added distribution levels, we've made quite a few deployments. The solution can support up to 1,00,000 endpoints. There's a specific customer that's using Vectra AI and has over 1,00,000 endpoints.

The solution’s technical support team is quite competent.

Positive

Vectra AI's initial setup is very simple. The Vectra AI team is quite competent, and they support and help us set everything up.

The solution's deployment was fairly quick. We had everything up and running within a day. Then, it was just about the information they were putting out that was being collected.

Vectra AI has an annual subscription license. You could choose the components you need for your environment. 

The solution had some very good integrations with firewalls and EDR solutions. Since Vectra AI is more of an internally-detection and response tool, it detects insider threats extremely well.

Before choosing Vectra AI, ensure you have a proper architect for your environment that shows you where all your blindspots could be. This makes the deployment a lot easier. Vectra AI detects threats that people miss, especially manual operators.

Vectra AI has helped save a lot of log analysts time because they don't have to deal with a lot of alert noise and false positives. Using Vectra AI for detection, triaging, and responses speeds up your soft response mechanism and makes the responses much quicker.

Overall, I rate the solution an nine out of ten.

We use Vectra with the assumption that our other defensive controls are not working. We rely on it to be able to detect anomalous activities on our network and trigger investigation activities. It's a line of detection assuming that a breach occurred or has been successful in some way. That's our primary use case.

We have it in some of other use cases, like anomalous network activity and detection for things. E.g., we are trying to refine or improve suspicious internal behaviours because we are a development technology company. We have developers doing suspicious things all the time. Therefore, we use it to help us identify when they are not behaving correctly and improve our best practices.

We have it predominantly on-prem, which is a combination of physical and virtual sensors. We also have a very minor element on the cloud where we are trialing a couple of components that are not fully deployed. For the cloud deployment, we are using Azure.

We are on the latest version of Cognito.

We have a limited use of Vectra Privileged Account Analytics for detecting issues with privileged accounts at the moment. That is primarily due to the fact that our identity management solution is going through a process of improving our privileged account management process, so we are getting a lot of false positives in that area. Once our privilege account management infrastructure is fully in place and live, then we will be taking on more privileged account detections and live SOC detections to investigate. However, at the moment, it has limited applicability.

We have a lot of technically capable people with privilege who are able to do things they should or should not be able to do, as they're not subject-matter experts when it comes to things like security. They may make a decision to implement or download a piece of software, implement a script, or do something that gets the job done for them. However, this opens us up to major security risk. These are the types of activities that the tool has been able to identify, enabling us to improve communication with those individuals or teams so they improve their business process to a more secure or best practice approach. This is a good example of how the solution has enabled us to identify when people are engaging in legitimate risky activities, and we're able to identify and engage with them to reduce risk within the network.

It has enabled our security analysts to have more time to look at other tools. We have many tools in place, and Vectra is just one of them. Their priority will always be to deal with intrusion attempt type of alerts, such as malware compromise or misuse of credentials. Vectra was able to simplify the process of starting a threat hunting or investigation activity on an anomaly. Previously, we weren't able to do this because the amount of alerts and volume of data were just too large. Within our security operations, they can now review large volumes of data that provide us with indicators of compromise or anomalous behaviour. 

By reducing false positives, we are able to take on more procedures and processes. We have about seven different tools providing alerts and reporting to the SOC at any one time. These range from network-based to host-based to internet-based alerts and detections. We are more capable to cover the whole spectrum of our tooling. Previously, we were only able to deal with a smaller subset due to the sheer workload. 

In some regards, I find that Vectra probably create more investigative questions. E.g., we need to find answers from other solutions. So, it is raising more questions than it is specifically answering. However, without Vectra, we wouldn't know the questions to ask in the first place. We wouldn't know what anomalies were occurring on our network.

Vectra data provides us with an element of enrichment for other detections. For example, if we see a detection going onto a single host, we could then look at that activity in Vectra to see whether there are suspicious detections occurring. This would give us the high percentage of confidence that the compromise was more severe than a normal malware alert, e.g., destructive malware or commander control malware enabling someone to pivot horizontally across the network. Vectra provides us with that insight. This enables us to build up an enriched view quickly.

One of the most valuable features of the platform is its ability to provide you with aggregated risk scores based on impact and certainty of threats being detected. This is both applied to individual and host detections. This is important because it enables us to use this platform to prioritize the most likely imminent threats. So, it reduces alert fatigue follow ups for security operation center analysts. It also provides us with an ability to prioritize limited resources.

It aggregates information on a host and host basis so you can look at individual detections and how they are occurring over time. Then, you can have a look at the host scores too. One of the useful elements of that is it is able to aggregate scores together to give you a realistic view of the current risk that the host plays in your network. It also ages out detections over time. Then, if that host is not been seeing doing anything else that fits into suspicious detection, it will reduce its risk score and fall off of the quadrant where you are monitoring critical content for hosts that you're trying to detect. 

When you are analyzing and triaging detections and looking for detection patterns, you are able to create filters and triage detections out. Then, in the future, those types of business usual or expected network behaviours don't create false positive triggers which would then impact risk scores. 

Without the detection activities that come from Vectra, we wouldn't have been able to identify the true cause of an event's severity by relying on other tools. This would have slipped under the radar or taken a dedicated analyst days to look for it. Whereas, Vectra can aggregate the risk of multiple detections, and we are able to identify and find them within a couple of hours. 

You are always limited with visibility on the host due to the fact that it is a network based tool. It gives you visibility on certain elements of the attack path, but it doesn't necessarily give you visibility on everything. Specifically, the initial intrusion side of things that doesn't necessarily see the initial compromise. It doesn't see stuff that goes on the host, such as where scripts are run. Even though you are seeing traffic, it doesn't necessarily see the malicious payload. Therefore, it's very difficult for it to identify these type of host-driven complex attacks.

It only shows us a view of suspicious behaviours. It doesn't show us a view of key or regularly attacked company targets. This could be because we don't have one of the other tools or products that Vectra provides, such as Stream or Recall. 

My challenge with the detection alerting platform, Cognito, is it tells us this host is behaving suspiciously and is targeting these other machines, but it won't give you a view when a host is the target of multiple attacks. This because you may have a key assets, such as domain controllers or configuration management servers. These are key assets which may get targeted. If you're a savvy attacker, you spread out your attack across multiple sources to try and hide them across the network. That is where the solution falls a bit short. It is trying to build that chain of relationships across detections and also trying to show detections from a perspective of a victim rather than the perspective of an attacker. I have expressed these concerns to Vectra and they are currently in as feature requests.

There is another feature in place which takes additional data feeds, such as DHCP IP allocation data. Their inputs are taken from Windows event logs, and that's the format they have in place. They use that to provide them with a more accurate view of host identities. If you are only relying on IP addresses, and IP addresses change over time, it's sometimes very difficult to show a consistent view of a system behaviour over time, as the IP can change per month. Unfortunately, because their DHCP data is taken from Windows host events and our DHCP data is taken from a Palo Alto system that generates the IP leasing, the formats are incompatible. I think taking different formats for that type of data is something else we have a feature request in for. At the moment, we don't have an accurate view, or confidence, that they are resolving when an IP address changes from host to host. So, we may be missing an accurate view of risk on some of those hosts. 

We also have the same problem with VPN and Citrix. E.g., if you're on the network and on IP address A, then you come in via the VPN, you're now on IP address B. Thus, if you're spreading your suspicious behaviour across both the internal network and VPN, then across Citrix, we don't get to join all that information up. They are seen as three different systems, so it causes a bit of a problem trying to correlate that type of event data.

If you include the proof of concept, I have been using Vectra for three years.

There are no concerns regarding the stability. It seems to be very reliable. I've had one sensor in two and a half years become corrupt and need to be rebuilt. That's it.

Day-to-day maintenance takes half an FTE to one FTE a day. There is no maintenance really required on the platform. All we need to do is monitor for when a health alarm occurs (a sensor is not working), then we raise the relevant request with the teams to investigate. Maintaining the health of the platform requires a feed into our operations team to be able to look at our monitor to determine when the health is degrading. Doing general health, like detection filters, triage filters, reviewing, looking for patterns and anomalies, and creating new filters, needs a daily dedicated FTE.

The scalability is brilliant. It is able to cope with virtual sensors. You can increase the hardware that supports the image and it will work with the high bandwidth of the data going through. There are no concerns in terms of the scalability.

It does create capture network data at scale because we have it deployed at over a 100 geographically split sites. We have over 8000 users on cloud. So, it's able to deal with the network traffic very easily, providing us with additional information. If we were just relying on things like firewalls and packet capture applications, we wouldn't get to that enrichment of a security context put on top of normal network traffic. 

Mainly, there are five people dedicated to using the platform: Tier 2 security analysts and an operations director. However, that is widen out to whomever we are raising the support requirements to, like the Tier 3s. When raised, we also enable the shared link so they can go into the platform and look at the data associated with the detection on that host. So, there is a wider volume of people who use the solution to get information for specifically requested cases. 

The technical support is very good. They always respond within a short amount of time to provide expert information and have always been helpful in trying to work through problems to find a good solution.

Previously, we had a general sensor solution taking logs. We didn't have an equivalent detection platform for our network nor did we have a tool capable of providing us with competent intrusion detection capabilities post-breach. Our main SIEM logging platform was generating over a 1000 alerts a day. It was bloated and unusable when trying to identify events/anomalies that were occurring. Once we implemented Vectra, it was able to give us a refined view and tell us which things we need to prioritize so we were able to reduce our workload from a 1000 alerts a day down to 10.

The initial setup was relatively straightforward. It was pretty much plug and play.

The initial pilot deployment took weeks, but that was because the scope kept on changing. However, the initial deployment only took hours. 

It has not helped us move work from our Tier 2 to Tier 1 analysts, but this is a fault in our implementation. The structure of our organization hasn't necessarily changed. We don't have Tier 1 security analysts. Therefore, we don't have the capacity or capability for them to deal with these types of detections. We have to leave our Vectra detection and activities with our Tier 2s.

We now have an implementation strategy. We have virtualized sensors in most locations rather than physical sensors. We only have physical sensors in the areas where there is high bandwidth traffic, such as key internal data centers. The virtual centers for local offices are sufficient for the volume of traffic there. We only deploy in areas that are key risks. We also only deploy and monitor network zones which are of significant risk, so we don't monitor our guest WiFi subnet nor do we monitor our development network subnets. Therefore, we keep our segregated networks and zoning structure consistent so we are able to only monitor for priority areas.

Vectra had an engineer come down. They plugged the device in and set it up. Since the firewall rules were already in place, it was working.

Assuming the firewall rules are already in place for the physical sensor, it needs one person plugging it in and putting it into a rack. If it is a virtual sensor, then it is just somebody who can deploy the virtual image onto the virtual infrastructure and switch it on. It takes two dedicated people to deploy. If you have a network team and a server team, then you will need one of each of those skill sets to be able to deploy the tool. It all depends on how your organization is structured.

It has increased our security efficiency because we can now do more with the tool. E.g., if we had a data analyst who was creating models and searching the data to identify the same types of the numbers/behaviours within Vectra, we would need at least two or three FTEs.

Vectra has reduced the time it takes us to respond to attacks. In 2019, we conducted a red team activity. The Vectra appliance was able to alert the red team on activity within three hours of the test starting. Prior tests to that, in real life or red team scenarios, we were potentially looking at days. However, we also tightened controls prior to that testing period. While Vectra has done an amazing job in reducing the time to respond, there are so many other things that we also have put in place which have contributed towards it.

Vectra has saved us weeks, if not months, in terms of the ability to identify a breach. Our process has been reduced down to hours, which is a potentially massive return on investment, if we were compromised. From an insurance perspective, the return investment is fantastic. 

From an FTE perspective, while it reduces the number of events that we have to look up and the number of alerts, we now have very specific things where we need to ask questions. Therefore, it's creating more work which we weren't capable of doing. 

At the time of purchase, we found the pricing acceptable. We had an urgency to get something in place because we had a minor breach that occurred at the tail end of 2016 to the beginning of 2017. This indicated we had a lack of ability to detect things on the network. Hence, why we moved quickly to get into the tool in place. We found things like Bitcoin mining and botnets which we closed quickly. In that regard, it was worth the money. Three years later, the license is now due for renewal so we will need to review it and see how competitive it is versus other solutions.

When we implemented the physical sensors, there were costs for support in terms of detection review sessions. We had a monthly session where an analyst would talk through the content, types of detections that they were seeing, etc. 

We have a desire to increase our use. However, it all comes down to budget. It's a very expensive tool that is very difficult to prove business support for. We would like to have two separate networks. We have our corporate network and PCI network, which is segregated due to payment processing. We don't have it for deployed in the PCI network. It would be good to have it fully deployed there to provide us with additional monitoring and control, but the cost associated with their licensing model makes it prohibitively expensive to deploy.

We did review the marketplace and look around. For example, we looked online at Darktrace, but we didn't run a side by side comparison to see which one would work better.

Vectra was the only tool in which we did a physical pilot or proof of concept. Vectra stood out for its simplicity and the general confidence that I had with the people whom I was engaging and having conversations with at that time. I am very much a people person. If I talk to people and don't get the impression they know what they're talking about, then that will reduce my confidence in their product. E.g., our initial engagement with Darktrace wasn't good enough to provide confidence in their platform, and we had to move quickly.

Make sure you have a dedicated resource committed to daily use of the tool. Because the selling point is it frees up your time, reducing the amount of time you need to spend on it so you don't have to commit resources. Then, you find yourself in an implementation two years later and you don't have committed resources who use it daily or are committed to it full-time. This means you don't maintain things like the triad rules and filters. Even though the sales material says it makes it easier and reduces alert fatigue, it doesn't give more time. You still need to have a dedicated resource to operate the tool, which we never committed at the beginning.

Having an established mature team structure is really important as well. Making sure people are aware of their role and how their role fits into the use of the tool is key. Whereas, we were building a security operation center (SOC) at the same time that we took on the tool, so our analyst activities have evolved around the incorporation of the tool into the organization and it's not necessarily a mature approach.

I would rate this solution as an eight (out of 10).

One of the biggest things is the visibility of stopping or identifying any infection as soon as possible. In this case, if someone downloads something malicious to their workstation, we have a number of controls in place. However, it wasn't so much the endpoint. It was the spreading of a worm type scenario or a WannaCry type thing. Anything that could potentially spread after the initial infection, which is where we wanted to come in and get that visibility.

It was key for us to have something that we could use for identifying as soon as possible, which would be call center initiated. That was probably our biggest thing: To push it in that direction, as we're a regulated company from the FCA. They drive us continually for improvement and behavioral analysis. Network analysis sort of falls into that bucket.

We already have a SIEM, which some people would argue gives us a lot of that visibility. It doesn't tend to give it the focus that we need. From Vectra, we get a lot of alerts of, "This is happening," or, "This is unusual." This is a lot easier than waiting for a couple of logs to come in, then a bit of AI logic at the back of it to potentially push it in that direction. It's very much for us to get a view of a potential attack, then deal with it as quickly as possible. To pinpoint where it's coming from, and where it is going to go.

One of the biggest things that I wanted to ensure is that it covered our call centers because that is where I see my biggest risk. So, I was really key on getting sensors across all geographic locations within the UK and in all of our small communication rooms.

It is all on-premise. We have a number of call centers spread around the UK. We look at all east-west traffic, as well as north-south. It all goes into our brain in our data center. We do have some branches out in Azure, but we're waiting on the new plugin that they are trying to develop. We are just starting in on our cloud journey and most of our infrastructure is in still private cloud. We haven't really gotten to the point where we have public cloud.

We're up-to-date, but I don't know the exact version number that we are on.

The key improvement for us were:

1. The additional monitoring 24/7, and using the high fidelity alerting from Vectra rather than SIEM, This was our biggest change. We have managed to leverage that rather more than our SIEM, which just throws out loads of spam. 
2. The FCA requirements to build on behavior monitoring.
3. The use case of the call center with its high turnaround of staff who are perhaps not as clued in or engaged in our user awareness program as they could be. 
4. Lack of end user deployment is another big improvement. We wanted something that was easy to deploy, or get up and running really quickly. It took a couple of weeks to rid of the alerts that we didn't want, but the actual involvement from the network teams was minimal, which was really good for us because we just don't have the resource to spend a lot of time trying to configure devices.

We use the solution’s Privileged Account Analytics for detecting issues with privileged accounts. Although I haven't seen a huge amount of alerts. We have a quarterly QBR, and they mentioned it the day before the QBR and noticed an alert pop up.

One of the key things for us is we have an annual pen test (an internal one), that's not as involved as a full red team. But, it's enough for the pen test to sit with the SOC guys, then we put the different tool sets together, what they're doing, and how that reacts to our Vectra,  SIEM, and endpoint AV. To see what picks up where, so it gives us an ability to check those tool sets that we have.

From a Vectra point, it will pick up a number of different things. But, it will also miss a number of different things. That's how pen testers work. They work covertly. So, it's really good for us to see what we can do and what we can't. Then, that feedback goes back to Vectra. We say, "Okay, well why didn't we pick up this?" They'll come up with a reason or they'll take it away and find something out about it. That's really good and a nice part of the service. We get to check to make sure the tool sets are working, but we also provide feedback and they're very open to that type of feedback.

I believe the solution has increased our security efficiency. It's hard to prove without having a direct attack. But, I get challenged about ransomware from my board, to say, "How do we defend against ransomware?" That's a big topic. One of the key things was when Vectra went in, it saw a developer run a script, which essentially changed the names for a number of files and put a different extension on, but they were doing some development type work. That's how their script ran, and it identified that as ransomware, which is a great thing to say. 

Although there was no encryption or malice involved, it did create new files, rename files, and delete old files, which essentially is what ransomware does anyway. It followed the same sort of logic to it,  I can report that back. "We do have some protection. It wouldn't stop it. But we could limit the amount of damage that it may do." 

I don't know about other companies, but I get the feeling most people look to identify rather than block. We're not a high-end bank. We are not going to stop people working. We're going to investigate what they're trying to do. That's just our risk appetite. We have to work. Unless it's absolutely 100 percent, we won't stop them. We would just look at it afterwards. So, all our alerting, we don't have any orchestration at the back of it to say, "Okay, if this happens, then I'm going to play that port in a firewall or I'm going to drop that from there." We won't do that. Humans will all be part of that process. We'll get a call, then we will make a crisis management team decision, etc. That's how we operate.

If, for instance, our AV doesn't pick it up. I think that is where Vectra will come in. So, if somebody gets infected and maybe hasn't picked it up. That's where, if that worm spread and our endpoint signatures weren't up-to-date, they went into zero day, and nobody knew about it. Vectra would give us that opportunity. It would potentially give us something that would say, "Well, this is not normal. This machine does not communicate with all these other machines like it is now." That's where we see it coming in. It gives us that extra chance to stop a disaster before it happens, or at least limit the amount of potential output of damage that that an incident can do.

Zero days are always very difficult. If the AV vendor doesn't know about it, it's not going to be able to tell me about it, stop it, quarantine it, or do anything. Having a tool set like this, which monitors network traffic for anomalies, it gives us that chance. I can't say that it definitely will pick it up, but there's another opportunity for us to reduce the amount of damage that can be done.

It gives us the point of where something is happening, which is the key thing for us. (I know that there is a back-end recall, which probably gives a lot more data, but we don't use that.) We then leverage our SIEM product to provide us logs from those specific sources that it's talking about, giving us that information. It is the accuracy of: It is happening here and on this particular host, then it's going to here to this particular host. It's that focus which is probably the most advantageous to us.

The logic behind Vectra's ability to reduce alerts by rolling up numerous alerts to create a single incident or campaign for investigation grows with severity, as there are additional alerts around that particular host. This is a useful feature rather than spamming alerts. But, we've never really had an issue with a lot of alerts. We really do triage our alerts quite well and have a good understanding of what does what. 

One of the key advantages for us is we define a 24/7 service around it. We use far more of Vectra alerts than we do with our SIEM product because we understand that when we get an alert from Vectra we actually need to do something about it. You can't really say you don't get false positives, as the action has happened. It's whether we consider that action as a concern rather than a SIEM that sort of gives you a bit of an idea of, "That may be something you're interested in." Whereas, Vectra says, "This has happened. Is this something you would consider normal?" I think that's the bit that we like. It just says, "Is this normal behavior or isn't this normal?" Then, it's up to us to define whether that is or isn't, which we like. 

The solution provides visibility into behaviors across the full lifecycle of an attack in our network, beyond just the internet gateway, because we do east-west traffic. So, it looks at the entire chain across there. We're fortunate enough not to be in a position that we've seen a meaningful attack. When we do have pen testers come in, we can see quite clearly how they pick traffic up and how it develops from a small or medium alert to go to higher severity, then how it adds all those events together to give more visibility. 

The solution does a reasonable job of prioritizing threats and correlating them with compromised host devices. We use that as how we react to it, so we leverage their rating system. We are reasonably comfortable with it. At the end of the day, we actually spend a lot of time and effort to tweak it. It's never going to be right for every company because it depends on what your priorities are within the company, but we do leverage what they provide. If it is a high, we will treat it as a high, and we will have SLAs around that. If it's a low, we'll be less concerned, and the events that come out pretty much lead to that. The events that we see and the type of activity going on, it makes sense why it's a low, medium, or high. Just because a techie has done a port scan, that doesn't mean we need to run around shouting, "Who has done this?"

When we originally put it in, it was really quite interesting to see. Picking up the activities from the admin user and what they were doing, then going, "By the way, why have you done that?" Then looking at a scan and going, "Well, how did you know that?" So, it's sort of cool to pick up that type of stuff. We tend to trust what it tells us.

Room for improvement depends on how their strategy and roadmap develops, as they have a lot of third-parties that they integrate with, e.g., more orchestration around what alerts and what to do with afterwards. They don't pretend to be working in that space. That is a third-party type activity.

There are always the little things that they could do a bit better, like grouping or triage filters. Clearly, they've taken that onboard and developed those over the course of the last 18 months to two years to put these additional functions in. My guys are constantly saying, "Oh, it'd be useful to do this and useful to do that."

The solution has not reduced the security analyst workload in our organization because we still need to SIEM. Unfortunately, while Vectra, for us, is a brilliant tool for network investigations, giving wonderful visibility, it doesn't go the whole way to replace our SIEM that is needed for compliance. So, I still have the same amount of alerting and logging that I did before. It gives us more defined ability to see incidents, but it doesn't give us enough information to satisfy a PCI or 27001 audit. 

I have been using this solution for about two years.

Interestingly enough, when we first got Vectra, we had a number of problems with it. The guys were all over the solution trying to fix it. It turned out to be a hardware issue. I think they ended up changing their supplier. They just ripped everything out and put a load of new equipment in. This was identified about three months after it being here. 

These things happen. There's not a lot you can do about it. However, they were really good and didn't make any excuses, apart from, "It can only be the hardware," which it was. Once they put the new hardware in, everything went really well.

Very few people are required for maintenance. We just generally run the alerts now. I have a guy spend probably less than an hour a day, maybe less than that, putting out fires and alerts. Then we investigate that, depending on its severity. The actual hardware maintenance is nothing. We'll just keep an eye on it or get an alert if an interface has gone down.

One of the biggest things that we wanted to implement was something that was easy to do. Our problem, as well as I'm sure a number of other companies, is the amount of resources to install these new technologies, then how the resource center operates and uses these technologies. It's great having all these additional add-ons here, there and everywhere, but my team is quite small. So, it had to be quite easy. It has to be quite focused. Hence, we went with Vectra.

At the moment, we have a hardware brain and are not near the limit of that. To go from that, I think Vectra was looking at some sort of applied solution, but it would then be a change. So, we're down to limitations of the hardware. I always say, "If we bought a massive company, we would probably have to redesign and architect the solution." At the moment, they made sure that we have some growing room. 

Our purchase was a one time thing for the entire company, otherwise we would be leaving ourselves exposed. Just this week, I took a Vectra device up to a new company that we purchased and stuck it in there. It is really that simple. We'll probably end up with a bit of traffic because we will see a lot of new servers and workstations that we have to do triage around.

We have probably 3,500 to 4,000 users across the UK. My team is quite small. I have a couple of guys who are cyber-related.

The technical support is brilliant and really responsive. That is probably down to the fact that they are a small company. Their guys respond instantly, normally within the day that they have somebody online and having a look at it, or they're putting it away and the communication is excellent. They will say, "Okay, we'll put it back to the developers," and then they give us updates, which is really efficient.

Vectra is growing at the moment. They support us very well. They do seem to rely on key people. Would my service be the same if they got rid of our technical manager? I don't know. They are a small, close family team, which is really good. Whether that would change when it's a few key people left, I don't know. But I know they are growing as a company as well, so let's hope they scale it in proportion to their customer base. Only time will tell. Other companies I've got at the moment grew too quickly in the services and service suffered as a part of that.

It isn't a tool set to replace a current tool set. It's just an additional feature. For me, it has only increased our workload, but that's because we had nothing there before.

We did not previously have a network monitoring solution. We have a toolset that does event log monitoring, but nothing across the network itself. I think we have basic flow visiblity, and the network team use that. However, there is no real way of investigating individual network packets, then using them for anything in particular.

The initial setup was easy. We have multiple sites, so we had to go around and travel to different sites. However, the actual brain was conifgured in a few hours. Once it was up, it was up. The network guys did nothing after that point. My guys probably spent a couple of days, over the course of a month just tweaking it. Then, it gradually goes down as we get a new server pop up, which might add a bit of additional alerting. Once we get a handle on that, then it comes down to something really quite manageable.

The priority for us was to get the main call center up and running at the start. We needed the brain up and do the implementation to see the east-west traffic in our call center. Then, we brought on additional sites, depending on the size around the UK, as we monitored it. 

We used the Vectra guys for the implementation. Our technical engineer came in, going into the data centers with our network engineer (or remotely), then set it up.

For the actual deployment within the data center and around the sites, just two people were needed one form each company. After that, it was the configuration of the alerting which took one of the SOC guys suing Vectra for reference.

They provide us a health check and provide us with recommendations on what we need to do every quarter, which is perfect. There is nobody else who does that. That is probably part of the advantage of being a smaller company. 

Once every quarter, they'll put health and safety in, and say, "Alright, these are the new functions. This is what you need to turn on. That's not quite working. Those haven't fired. You might want to look at removing those." This is really good to see, because I get a lot of vendors, who once they've sold you a technology, they don't really care. They go, "Yep, there you go." They don't look at what you installed, how you've installed it, provide any recommendations, or look at how it's performing. 

This provides me the assurance my SOC guys are doing a good job, we are on top of any changes and the assurance we are getting the most of the solution.

Vectra has pretty much forced this upon us, which is really good because everyone is very busy. Before you know it, the months turn to years and disappear. 

ROI is a difficult one for security tools. You can argue that if you don't see anything where you did investment, this is the reason to have good security tools: not to have an incident. You only really know when bad things happen, and you're in the middle of it. Otherwise, it's doing what it needs to do to stop or identify an issue in the first place.

We are running at about 90,000 pounds per year. The solution is a licensed cost. The hardware that they gave us was pretty much next to nothing. It is the license that we're paying for. I think if we outgrow our current hardware, then we will have a look at bigger hardware or some sort of distribution. I'm sure they have a number of different options for larger companies. I don't see that being a major issue for us in the next three to five years.

We don't have complete visibility because we don't have all of that metadata surrounding it. Sometimes there might be more metadata before, it might be something afterwards, or there might be something missing, but we accept that because we don't have the funds to pay for the additional functionality that it can provide its a trade off.

When we started off, apart from money, we had to look at behavioral analysis. We weren't sure where we wanted to go with the solution, whether we wanted to look at the endpoint or network. So, after a RFI, to define which direction we wanted to go, we thought that we would go down the network analysis route.

Because we have call centers, there is normally a high turnover of staff. The jobs themselves are quite intense and people move around quite a lot, it was key for us to get some visibility in what those guys are doing. We thought, "Although we do a lot of user awareness and logging, this is probably where our weakest link is." It was a case of somebody potentially clicking on a malicious link, some sort of phishing attack which was probably, or is probably, going to cause us the most pain.

We looked at Darktrace and there was another option that dropped out. So, we looked at the main players in that area. We decided on the behavior analysis for network, then we took the top three: Vectra, Darktrace, and another solution. 

It came down to Darktrace and Vectra. Darktrace looked much prettier than Vectra, unfortunately the support that we'd heard about and reviews that we read, led to, "Here's the new tool set. Off you go". This is what we didn't want. We wanted somebody to hold our hand, then give us the support we needed to ensure we get the best out of the tool set.

It obviously comes down to price as well and we feel we picked the best product that fitted us. We did quite a lot of due diligence on both. I went to different places that got both installed and got references from both. I firmly believe that both products would have done the job well. However, the support from Vectra along with their customers' references to say how good it was, I think we made made the right decision.

People do a lot more than we actually see. Looking at the test and development guys, sometimes they do things that they don't understand. So, they will do it because it works. The actual things that are behind the scenes are the sort of things that happen, and they don't really understand. If there's something that's really complicated, they're people that have initiated it that don't really know what it is. That is always a problem, because in our sort of company, we have a lot of developers who are doing a lot of coding and things like that, but they're not 100 percent on all the other things that they affect, such as the supporting applications underneath it. 

They are making a change on one particular app, but it's using the other apps underneath it to develop that and push that across to something else. All these extra, different steps that they are completely oblivious to where we go, "Actually, you've just done this." They go, "Well, I don't know, I just ran the script over here. I don't know why that would happen." But, it'll do a LDAP lookup or connect to a share. Those are the sort of things that you get a lot of visibility from people who don't understand. So, that can become tricky. That's pretty much par for the course for a lot of security tool sets. Where you have a couple of people who know one particular aspect, but don't really understand everything that's going on. To be fair, IT is a big area. You can't expect everyone to know everything of everything, not when you're not working in a massive IT structure, and the security team is a small department.

You need to be quite key on your business case and what you're expecting from it. Be 100 percent sure on your use cases. It's an excellent tool. It doesn't create a huge amount of overhead, but it is a tool that you need to keep on top of. The more you keep on top of it and get it right at the start, the easier it will make your life going forward. Don't just stick it in, then leave it to whirl away as a lot of people do. You have to spend that bit of extra time, and it's not huge amount of time, and leverage other teams. 

The way they do their customer success is really good. There's nothing bad that I've got to say apart from the costs, but nothing's free, is it?

It has to be up there with my favorite security tool set at the moment. I am quite lean on scores, but the solution is definitely nine (out of 10). If I look at all my other security tool sets, this is the one that my guys value the most.

Our primary use case for this solution is for security policy and to detect potential attacks on our networks.

This solution helped our mean time to identify as we can have more precise detection and documentation. At the moment, we're seeing daily detection of between 10 and 20 and if it's on the cloud, we can do 50 to 100 per day.

As we are just beginning to use Vectra AI, I find the simplicity of implementation to be quite valuable. The UI is easy to use and when we send detection to everybody, they easily understand what we are asking at the time. The sections are very precise. 

There is room for improvement in the documentation. We would like to have more details on how it detects what we see. 

I have been using Vectra AI for about four months.

This solution is stable.

This solution is quite scalable. In the beginning, we had one point of network capturing the traffic. After that, we added two points on top of it and it worked perfectly. At first, we had five gigabits per second and now we have 30 so I'll say it's a good service.

I would rate their support a ten, on a scale from one to ten, with one being the worst and ten being the best. The reason for this rating is that they were with us every step of the way to help and guide us through the process seamlessly.

Positive

Prior to Vectra AI, we used Gatewatcher and Microprobes and also the IPS/IDS firewall. Vectra AI is an additional layer of security.

My opinion – and a strong point for Vectra AI – is that the deployment is not complex and is quite straightforward. It was an easy deployment and someone from the company helped us on each point and guided us through important milestones. If I recall correctly, it lasted for about two weeks.

It's a bit expensive, as you can have a lot of different solutions for free. So, in the beginning, it's more expensive, but as time passes it gets better.

The issue Vectra AI helps us solve is threat prevention.

Overall, I would rate this solution a seven, on a scale from one to ten, with one being the worst and ten being the best. The reason for this rating is that we are still in a tuning phase and it's too early to say anything about detection, but I would put ten for support.

We need to move our whole data traffic over the core switches. We also want to secure our network and have it integrated into our vCenter and into our Active Directory.

We have 18,000 IP addresses, and in Recall, we have uploads from about 250 GB per day.

One year ago, we found notebooks that were compromised with Emotet. Vectra saw that the client performed search requests to the Active Directory for a keyword root and contacted domains that are known for Emotet.

Vectra AI also found that a notebook had permanent contact with a domain outside our network.

We often use the new feature to create PCAP files from the whole data traffic. It makes it much easier to find network problems such as whether the server is responding to a request. It has nothing to do with security, but it helps a lot to find other problems.

Vectra AI helped improve our mean time to identify. For example, the Sophos client doesn't recognize anything, and without Vectra AI, we wouldn't be able to identify problems. It does it quickly.

We use the Sidekick MDR service. It's very important to us because it gives us another layer of security and a second pair of eyes. We have learned a lot from the Sidekick.

For S&D account scans, it would be easier if Vectra AI could triage with users. If a client uses a lot of accounts, then it could indicate that these accounts are benign, for example. That would help a lot.

I've been using Vectra AI since 2020.

We have not had any problems with stability.

Vectra's technical support is very fast. They have been able to resolve the tickets I created very quickly. I would rate technical support a ten out of ten.

Positive

The initial deployment is easy. You have to give them an IP address, plug it into the switch, and then get started.

We have seen an ROI. The cost of security breaches outweighs the cost of Vectra AI.

Vectra AI is not a cheap solution.

We evaluated Vectra AI and CyberSense and did POCs with both. We observed that Vectra AI was better because we can see everything. CyberSense uses a different technology. For example, it creates an Active Directory that isn't used. If someone connects to this Active Directory or starts requests, then we will get an alert. However, we think Vectra uses a better way because we can see more. It also has better technology.

Overall, I would rate Vectra AI at ten on a scale from one to ten, with ten being the best.

Vectra was deployed to give us a view of what is happening on the user network. It helps us to check what is being done by users, if that is compliant with our policies, and if what they're doing is dangerous. It covers cyber security stuff, such as detecting bad proxies, malware infections, and using packet defense on strange behaviors, but it can also be used to help with the assessment of compliance and how my policies will apply.

We also use Vectra to administer servers and for accessing restricted networks.

There are on-prem modules, which are called Cognito Detect, the NDR/IDS solution, which captures traffic. We also have the SaaS data lake, and we also have the Cognito Detect for Office 365, which is a SaaS-type sensor within the O365 cloud.

If we didn't have Vectra and the Detect for Office 365, it would be very difficult to know if our Office 365 was compromised. We tried, in the past, to do it with a SIEM solution consuming Office 365 logs and it was really time-consuming. The Office 365 Detect solution has the exact same "mindset" as the Detect solution for networks. It's almost like we can deploy it in the fire-and-forget mode. You deploy the solution and everything is configured. You have all the relevant alerts out-of-the-box. If you want to, you could tweak, configure, contextualize, and rewrite the parser, because some things might be out of date,  and customize the solution. For a big company with a large team it might be feasible, but for small companies, it's an absolute showstopper. The Detect for Office 365 gives us a lot of visibility and I'm very pleased with the tool.

We use three services from Vectra: Cognito Detect, Detect for Office 365, and Cognito Recall, and we are leveraging all these services within the SOC team to have proper assessments. We even use these tools to prepare the new use cases that we want to implement into our SIEM solution. Recall stores all the metadata that is brought up from Cognito Detect at a central point, data-lake style, with an elastic stack and a Kibana interface available for everybody. Using this, we can try to see what are the general steps.
Without this, I would not have been able to have my SOC analyst do the job. Creating a data lake for cyber security would be too expensive and too time-consuming to develop, deploy, and maintain. But with this solution, I have a lot of insight into my network.

An additional thing that is very convenient with the Recall and Detect interfaces is that you can do use cases involving individuals in Recall and have them triggered in Detect. For example, we found ways to track down if users are trying to bypass proxies, which might be quite a mess in a network. We found a type of search within Recall and have it triggering alerts in Detect. As a result, things can be managed.

It's so efficient that I'm thinking about removing my SIEM solution from our organization. Ours is a small organization and having a SIEM solution is really time-consuming. It needs regular attention to properly maintain it, to keep it up and running, consume all the logs, etc. And the value that it's bringing is currently pretty low. If I have to reduce costs, I will cut costs on my SIEM solution, not on Vectra.

The solution also provides visibility into behaviors across the full life cycle of an attack in our network, beyond just the internet gateway. It provides a lot of insight on how an attack might be coming. There are multiple phases of an attack that can be detected. And there is a new feature where it can even consume intelligence feeds from Vectra, and we can also push our own threat-intelligence feeds, although these have to be tested. The behavioral model of the Detect solution also covers major malware and CryptoLockers. I know it's working. We tested some cases and they showed properly in the tool. I'm quite reassured.

It triages threats and correlates them with compromised host devices. One of the convenient things about Detect is that it can be used by almost anybody. It's very clear. It's quite self-explanatory. It shows quadrants that state what is low-risk and what is high-risk. It is able to automatically pinpoint where to look. Every time we have had an internal pen test campaign, the old pen test workstation has popped up right away in the high-risk quadrant, in a matter of seconds. To filter out false positives it can also provide rules that state, "Okay, this is the standard behavior. This subnet or this workstation can do this type of thing." That means we can triage automatically. It also has some features which aren't so obvious, because they are hidden within the interface, to help you to define triage rules and lower the number of alerts. It looks at all your threat or alert landscapes, and says, "Okay, you have many alerts coming from these types of things, so this group of workstations is using this type of service. Consider defining a new, automated triage rule to reduce the number of alerts."

To give you numbers, with my SIEM I'm monitoring some IDS stuff within my network. Everything is concentrated within my SIEM. From my entire site, IDS is giving me about 5,000 more alerts than my Vectra solution. Of course it will depend on how it is configured and what types of alerts it is meant to detect, but Vectra is humanly manageable. You don't have to add something to make the triage manageable, using some time-consuming fine-tuning of the solution, requiring expertise. This is really a strong point with Vectra. You deploy it, and everything is automatically done and you have very few alerts.

Its ability to reduce false positives and help us focus on the highest-risk threats is quite amazing. I don't know how they made their behavioral or detection models, but they're very efficient. Each alert is scored with a probability and a criticality. Using this combination, it provides you insights on alerts and the risks related to alerts or to workstations. For example, a workstation that has a large number of low-criticality alerts might be pinpointed as a critical workstation to have a look at. In fact, in the previous pen test we launched, the guys were aware that the Vectra solution was deployed so they tried some less obvious tests, by not crawling all the domain controllers, and things like that. Because there were multiple, small alerts, workstations were pinpointed as being in the high-risk quadrant. This capability is honestly quite amazing.

And, of course, it has reduced the security analyst workload in our organization, on the one hand, but on the other it has increased it. It reduces the amount of attention analysts have to pay to things because they rely on the tool to do the job. We have confidence in its capability to detect and warn only on specific things of interest. But it also increases the workload because, as the tool is quite interesting to use, my guys tend to spend some time in Recall to check and fix things and to try to define new use cases. Previously, I had four analysts in my shop, and every one of them was monitoring everything that was happening on the network and in the company on a daily basis. Now, I have one analyst who is specialized in Vectra and who is using it more than the others. He is focusing on tweaking the rules and trying to find new detections. It brings us new opportunities, in fact. But it has really reduced the workload around NDS.

In addition, it has helped move work from our Tier 2 to our Tier 1 analysts. Previously, with my old IDS, all the detection had to be cross-checked multiple times before we knew if it was something really dangerous or if it was a false positive or a misconfiguration. Now, all the intelligence steps are done by the tool. It does happen that we sometimes see a false positive within the tool, but one well-trained analyst can handle the tool. I would say about 20 to 30 percent of work has moved from our Tier 2 to our Tier 1 analysts, at a global level. If I focus on only the network detections, by changing all my IDS to Vectra, the number is something like more than 90 percent.

It has increased our security efficiency. If I wanted to have the same type of coverage without Vectra, I would need to almost double the size of my team. We are a small company and my team has five guys in our SOC for monitoring and Tier 1 and Tier 2.

It reduces the time it takes for us to respond to attacks. It's quite difficult to say by how much. It depends on the detections and threat types. Previously, we had an antivirus that was warning us about malicious files that were deployed on a workstation within one year. Now, we can detect it within a few minutes, so the response time can be greatly enhanced. And the response time on a high-criticality incident would go from four hours to one hour.

The most valuable feature for Cognito Detect, the main solution, is that external IDS's create a lot of alerts. When I say a lot of alerts I really mean a lot of alerts. Vectra, on the other hand, contextualizes everything, reducing the number of alerts and pinpointing only the things of interest. This is a key feature for me. Because of this, a non-trained analyst can use it almost right away.

It's very efficient. It can correlate multiple sources of alerts and process them through specific modules. For example, it has some specific patterns to detect data exfiltration and it can pinpoint, in a single area, which stations have exfiltrated data, have gathered data, and from which server at which time frame and with which account. It indicates which server the data is sent to, which websites, and when. It's very effective at concentrating and consolidating all the information. If, at one point in time, multiple workstations are reaching some specific website and it seems to be suspicious, it can also create detection campaigns with all the linked assets. Within a single alert you can see all the things that are linked to the alert: the domains, the workstation involved, the IPs, the subnets, and whatever information you might need.

The key feature for me for Detect for Office 365 is that it can also concentrate all the information and detection at one point, the same as the network solution does. This is the key feature for me because, while accessing data from Office 365 is possible using Microsoft interfaces, they are not really user-friendly and are quite confusing to use. But Detect for Office 365 is aggregating all the info, and it's only the interesting stuff.

We are still in the process of deploying the features of Detect for Office 365, but currently it helps us see mailboxes' configurations. For example, the boss of the company had his mailbox reconfigured by an employee who added some other people with the right to send emails on his behalf, and it was a misconfiguration. The solution was able to pinpoint it. Without it, we would never have been able to see that. The eDiscovery can track down all the accesses and it even helped us to open an incident at Microsoft because some discoveries were made by an employee that were not present in the eDiscovery console on the protection portal from Office 365. That was pinpointed by Vectra. After asking the user, he showed that he was doing some stuff without having the proper rights to do so. We were able to mitigate this bit of risk.

It also correlates behaviors in our network and data centers with behaviors we see in our cloud environment. When we first deployed Vectra, I wanted to cross-check the behavioral detection. After cross-checking everything, I saw that everything was quite relevant. On the behavioral side, the Office 365 module can alert us if an employee is trying to authenticate using non-standard authentication methods, such as validating an SMS as a second factor or authenticating on the VPN instead of the standard way. The behavioral model is quite efficient and quite well deployed.

Vectra is still limited to packet management. It's only monitoring packet exchanges. While it can see a lot of things, it can't see everything, depending on where it's deployed. It has its limits and that's why I still have my SIEM.

I am in contact with the Vectra team, if not weekly then on a monthly basis, to propose improvements. For the time being, the main improvement I can see would be to integrate with more external solutions. Since Vectra provides an API, that  should be quite easy to handle. For example, we're using an open source ticketing system within our team and I want to have it handled properly by Vectra. We'll go forward on that with the API. 

Another area for improvement that I have pinpointed is that the Office 365 solution and the Detect solution cannot match the same users. That means we have two "different worlds" currently, the world from Office 365, which is bringing alerts based on users' emails and email addresses. And we have the network world, which is bringing an Active Directory view. On the one hand we are seeing emails or email addresses, and on the other hand we are seeing things like logons on to the domain controller. From time to time, it does not match and the tool cannot currently cross-check this info and consolidate everything. I would like to be able to see that detection related to one workstation and covering a user: what he is using, what services he is using, and what he did with his Office 365 and configuration. That would help. 

Another major feature would be to have all logs pushed to Cognito Detect, and all these logs should be also pushed to Recall. Currently, within Recall, I can't call up the Office 365 detections and I would love to do so. 

The last point would be an automated IoT threat feed consumption by the tool.

I have been using Vectra for two years.

The stability is absolutely flawless. The last time it was rebooted was almost two years ago. 

The only thing we have seen was some interruption in log feeding to the Recall instance, the SaaS solution. I had a quick call with a product manager in Europe and he was very keen to share information about this issue and willing to improve it.

So, within two years we have faced one stability incident. This incident lasted less than two hours and it was not on the monitoring solution but more on the data lake solution.

The scalability is very good. From the financial perspective, we are not limited by the number of sensors. We can deploy as many virtual sensors as we want. The key factor is the IP addresses that are being monitored. In terms of technical scalability, we have one brain appliance, one very big sensor, and multiple virtual sensors, and I don't see any limits with this solution.

We are currently using all the things that it's possible to use in this solution. One thing I like with Vectra is that it's updated very frequently. Almost every month new features are popping up: new detections, new dashboards, new ways to handle things. That's quite good. I work with our SOC team so that they can use everything right away.

The tech support is surprisingly good. We had questions, we faced some slight issues, and we always got very quick answers. Things are taken into account within a few minutes and answers usually come in less than two hours.

To deploy Recall, which is the data lake in SaaS, or to deploy the Office 365 sensor, it was effortless. It was just a quick call and, within minutes, everything was set up.

It was set up the same way the solution is behaving. It's a turnkey solution. You deploy it and everything works. The configuration steps are minimal. It's exactly the same for the SaaS solution. You deploy the tool and you just have to accept and do very basic configuration. For Office 365, you have to grant rights for the sensors to be able to consume API logs and so on. You grant the rights and everything is properly set up. It's exactly the same for Recall. It was a matter of minutes, and not a matter of days and painful configurations.

In terms of maintenance it is very easy and takes no time. It's self-maintaining, aside from checking if backups have properly ended. And in terms of deployment, when we add a network segment, we have to work a bit to determine where to deploy the new sensors, but the deployment model is quite easy. The Vectra console is providing the OVA to provide a virtual sensor for deployment. It can also automate the deployment of the sensor if you link it with vCenter, which we have not done. But it's very easy. It's absolutely not time-consuming.

If I compare the deployment time to other solutions, it's way easier and way quicker. If I compare it to my standard IDS, in terms of deployment and coverage, it's twice or three times better.

We were in contact with Vectra a lot at the beginning to plan the deployment, to check if everything was properly set up. But the solution is quite easy to set up. The next decisions we had were focused on how to enhance the solution: what seemed to be missing from the tool and what we needed for better efficiency.

The guys from Vectra were more providing guidance in terms of where the sensors needed to be deployed and that was about it.

We had a third-party integrator, Nomios, that provided the appliances, but they did not do anything aside from the delivery of appliances to our building. Our team took the hardware and racked it into the data center on its own. With just a basic PDF, we set up the tool within minutes. The integrator was quite unnecessary.

Nomios are nice guys, but we have deployed some of other solutions with them and we were not so happy about the extra fees. We were not the only ones who were not happy about that. We tried to deploy the ForeScout products with Nomios and it was quite a mess. But they have helped us with other topics and they have been quite efficient with those. So they are good on some things and on other things they are not good.

It's ineffective to speak just about the cost of the solution, because all the solutions are costly. They are too costly if we are only looking at them from a cost perspective. But if I look at the value I can extract from every Euro that I spend on Vectra, and compare it to every Euro I spend on other solutions, the return on investment on Vectra is way better.

ROI is not measurable in my setup, but I can tell you that Vectra is way more cost-efficient than my other solution. The other solution is not expensive, but it's very time-consuming and the hardware on which it's running it's quite expensive. If I look at the global picture, Vectra is three or four times more cost-efficient than my other solution.

The pricing is very good. It's less expensive than many of the tools out there.

I evaluated Darktrace but it wasn't so good. Vectra's capabilities in pinpointing things of interest are way better. With Darktrace, it is like they put a skin of Kibana on some standard IDS stuff.

Vectra enables us to answer investigative questions that other solutions are unable to address. It provides an explanation of why it has detected something, every time, and always provides insights about these detections. That's very helpful. Within the tool, you always have small question marks that you click on and you have a whole explanation of everything that has been detected: Why has it been detected and what work is the recommended course of action. This approach is very helpful because I know that if I ask somebody new, within our team, to use Vectra, I don't have to spend months or days in training for him to be able to handle the solution properly. It's guided everywhere. It's very easy to use.

Do not be afraid to link Vectra to the domain controller, because doing so can bring a lot of value. It can provide a lot of information. It gets everything from the domain controller and that is very efficient.

You don't need any specialized skills to deploy or use Vectra. It's very intuitive and it's very efficient.

We are in the process of deploying the solution’s Privileged Account Analytics for detecting issues with privileged accounts. We are using specific accounts to know whether they have reached some servers. It's quite easy with all these tools to check whether or not a given access to a server is a legitimate one or not.

We don't use the Power Automate functionality in our company, but I was very convinced by their demonstration, and an analyst in my team played with it a bit to check whether or not it was working properly. These are mostly advanced cases for companies that are using Office 365 in a mature manner, which is not the case for our company at the moment.

In our company, less than 10 people are using the Detect solution, and five or six people are using Recall. But we are also extracting reports that are provided to 15 to 20 people.