What is our primary use case?
One of the interesting things that made us lean towards going with Awake was that it fulfilled a couple of use cases. One was the core NDR functionality. We wanted it to be able to monitor our network traffic and alert us on security-relevant events.
Another request we had was that because our security team was pretty resource-constrained, we wanted a solution that could provide an in-house managed service for monitoring it, as a partner. Awake was able to provide that, with their MNDR team. and that was something that we found pretty valuable.
How has it helped my organization?
Awake's MNDR has affected our overall security posture very positively. Having a team that is able to monitor our network activity has been a huge help.
The solution uncovers the entire attack surface for the environments we're using it in. That is one of the important reasons we brought in Awake, and in general, network monitoring. We wanted to be able to have that visibility at the base layer, at the network layer, into things that may not be covered by other monitoring tools. For example, EDR won't cover shadow IT and systems that simply don't have endpoint protection installed. Awake will at least help us be aware of those and monitor suspicious activity at the network level.
Overall it has improved our InfoSec operations in that it frees up our security engineers from having to triage every little thing that might show up on the network and, instead, rely on Awake—the combination of their technology and the people on their MNDR team—to help offload that work from us.
It tracks both managed and unmanaged devices, the way we have it set up. And that is definitely of value to us because otherwise we wouldn't have a lot of visibility into the unmanaged devices. Awake has helped us identify things like personal devices that were improperly and inappropriately connected to our corporate network. It has helped us to identify devices in the R&D environment that weren't managed. Maybe they were some legacy system that's been sitting around for a while, or an R&D engineer hooked up some custom Linux device to the network. Awake has helped us be aware of those kinds of things. We feel better that Awake is monitoring those kinds of unmanaged devices. We wouldn't have as much visibility into the activity if we didn't have Awake.
In terms of productivity, it wasn't that we had an existing team monitoring the network and that we ended up with a more effective or productive workflow after onboarding Awake. More importantly, we simply didn't have much network visibility before Awake. It speeds up response times but, more importantly, we are now able to respond to things that we simply weren't seeing before.
What is most valuable?
The query language that they have is quite valuable, especially because the sensor itself is storing some network activity and we're able to query that. That has been useful in a pinch because we don't necessarily use it just for threat hunting, but we also use it for debugging network issues. We can use it to ask questions and get answers about our network. For example: Which users and devices are using the VPN for RDP access? We can write a query pretty quickly and get an answer for that.
It provides us with the base level of what we would hope can be obtained from monitoring encrypted traffic, things like TLS and SNI. We get to see which supposed hosts they're trying to hit. And we get the metadata around encrypted traffic. Awake, as I understand it, does have heuristics and alerts for that. It's good to see that in place because some of the other products we've seen don't handle encrypted traffic well. Whereas no one can truly look deeply into encrypted traffic, what we've seen from Awake is that it is at least looking at the metadata and analyzing the metadata of encrypted traffic, and that's useful.
What needs improvement?
One concern I do have with Awake is that, ideally, it should be able identify high-risk users and devices and entities. However, we don't have confidence in their entity resolution, and we've provided this feedback to Awake. My understanding is that this is where some of the AI/ML is, and it hasn't been reliable in correctly identifying which device an activity is associated with. We have also encountered issues where it has merged two devices into one entity profile when they shouldn't be merged. The entity resolution is the weakest point of Awake so far. Even without that it's useful because with the MNDR team, they'll at least do some of that work for us and then we can follow up on certain things. But that is something that we would want to see improved.
Because we have the MNDR team, in some ways we don't work as hands-on with the interface itself as we did before. But another thing that would be helpful would be easier ways to integrate it with other systems. The integrations seem to exist, but they're a little weak in terms of how easy they are to set up, or what kind of information can be pulled in. That's something they've said that they're working on, as part of their roadmap, but that is something that I would like to see improved.
For how long have I used the solution?
We have been using Awake Security Platform for about half a year.
What do I think about the stability of the solution?
We have not had issues with the stability. It's pretty much always available when we need it. We're not concerned about that, whereas we do have issues with stability with other products.
What do I think about the scalability of the solution?
We haven't encountered too many scalability issues yet, but we haven't really tested scalability. We haven't tried running a massive amount of artificial network traffic through it, but for our purposes, it has been performing fine.
We expect to increase usage in the future because the InfoSec team is growing and we have more bandwidth. Our strategy for onboarding Awake was always with the awareness that our InfoSec team was very small. When we onboarded it, we needed that additional external resource, the MNDR team, to help us monitor the network as well as the appliance itself to provide visibility. But when we were evaluating Awake, we also saw that there was a growth path, that there are more capabilities to the appliance and it's an appliance that we can dive into, hands-on, ourselves. As the team grows, it's something that will grow with us and allow us to get more immersed in, ourselves.
How are customer service and technical support?
Technical support has been good. The good news is that we haven't had to utilize their technical support too much, and when we have had issues, like the SFP transceiver that was shipped with the product, they've been pretty responsive about getting them fixed.
My impression is that their MNDR team has been pretty proactive about notifying us of events. Their expertise seems pretty reasonable. When we've had the monthly reviews of events with the person they have assigned to our account—when we have questions like, "Hey, why did this alert come up?" Or "What does this mean exactly?"—they've been pretty willing to either answer the question on the spot. Or if that person doesn't know, they've been willing to to go back and follow up with the team on that. They've been pretty responsive and we haven't had any concerns.
Which solution did I use previously and why did I switch?
We were not comprehensively using a previous solution. We had firewalls with DPI enabled but that's not the same thing as Awake being able to monitor internal traffic as well. We needed this kind of core capability.
How was the initial setup?
The initial setup was fairly straightforward. We deployed the sensor on-premises and then we deployed other sensors at other sites. We have our own VPN tunnels between sites, so working with Awake's team and our IT team didn't to be a huge problem. We did run into one small issue, having the wrong SFP transceiver for one of the appliances, but that was just a logistical issue, it had nothing to do with the technology itself.
The initial deployment, so that we could start seeing visibility on a lot of our traffic, was very quick, and took a week or two. Part of that time was just the physical aspect, especially during quarantine, of needing to get someone physically out to the office to rack it up and hook it up. I have no particular concerns about the deployment. It went pretty smoothly overall.
One of the good things that they had was a site survey and that got the conversation rolling regarding what connectivity we would need across sites, and what the basic strategy would be. That strategy was, "Okay, let's start with a combined sensor-plus-hub appliance at HQ and, from there, we'll just ship smaller appliances out to our various branch offices—the ones that we are initially bringing onboard."
As for maintenance of Awake Security, we almost require no one, which is good. The maintenance really hasn't been a problem. Once we make sure that the physical appliances are racked and stacked, they pretty much stay where they are. Occasionally, if we have a new office, it's pretty easy. We talk to Awake, we buy a new appliance, it gets shipped out to where we need it to be, and we rack and stack it. But once it's in place the maintenance is very low.
We have about five people who are users of Awake, although that's changing. It continues to grow as we onboard new staff. We have security engineers who use Awake. They're not analysts, they're engineers, so they don't monitor it but they will occasionally use it because it does have that query language. We also have our IT engineers who occasionally coordinate with Awake when Awake says there's a new version available. Awake will coordinate a time to upgrade. That has generally gone pretty smoothly.
I think they're still a little bit of a startup, even internally at Arista, because occasionally things get dropped. For example, it wasn't a version upgrade, but we upgraded to a new appliance because the one that we had picked for our PoC ended up being a little undersized. We had to expand the scale of the appliance as we brought on new offices. Things like the user accounts didn't get transferred over as we would have expected. That was a little bit of a hiccup but nothing too concerning.
What about the implementation team?
We only worked with Awake, which is what we prefer. We like things that we can deploy and implement ourselves, just with the vendor, that don't require professional services.
On our side, the deployment was done by a network engineer and assistant engineer.
What was our ROI?
For a security tool, ROI is always a little harder to get at. Was there some breach that could have happened if we didn't have Awake? Maybe. We don't really know and can't quantify it concretely.
But it does save time for us not having to manually correlate across different network devices to investigate something funny that's happening. Instead, we essentially have the Awake team monitoring it for us and making us aware of any kinds of funny activity. Beyond that, there have been time savings because of one of our use cases which is using the query language to debug and ask questions of the network. We can do that instead of having to manually correlate across systems.
What's my experience with pricing, setup cost, and licensing?
The pricing seems pretty reasonable for what we get out of it. We also found it to be more competitive than some other vendors that we've looked at.
We paid for the appliances and for the MNDR and the pricing was fairly comprehensive. There wasn't any nickel and diming.
Which other solutions did I evaluate?
We evaluated Corelight, which commercializes the open source solution Bro, or as it's now known, Zeek. We also evaluated Darktrace as well as a couple of other vendors that are new in the space with solutions that claim more of an AI/ML-based approach. Vectra AI was one of them. We also evaluated Extra Hop. We didn't go into a full PoC with most of these because it would have been too much for us. We sat through a variety of demos and technical discussions with the vendors. We only PoC'ed Darktrace and Awake.
Between Darktrace and Awake, Awake was a lot more hands-off, which was good for a smaller team starting out. But at the same time, it was also more understandable. The query language made sense, meaning it was learnable and we could see ourselves using it in the future. Whereas, with Darktrace, it was more of a black box. It tended to have a lot more noise for us.
I'm not as convinced about the AI/ML portion and that's not why we went with Awake. I understand that there's some AI/ML in it, although I don't have a lot of insight into what that does, but we like the fact that it also has more standard and traditional heuristics. They have this query language where you can write heuristics to alert on certain kinds of interesting events. We really like that because it is more understandable in many ways than a pure AI/ML-based solution, the kinds we've seen from other vendors.
What other advice do I have?
One thing to be aware of, for someone else using Awake, is to be ready, at the beginning, to clearly define what is expected network activity and what is not. That helps both teams. For us, it has been an interesting challenge because our network is quite complex. In the life sciences, we have pretty varied environments for physical manufacturing, R&D, and SGNA. It spans the whole gamut. What helps in that environment is being very clear, up front, about documenting and giving context to the Awake MNDR team about which devices are domain controllers and the kinds of traffic they should expect from them; which subnets are segmented off in different ways so that they should not expect certain kinds of traffic from them. Include what kinds of applications you have at the company, applications that are approved or behaviors that are approved, so that they know to tune their models to not alert on that. Getting a better picture, if possible, ahead of time, so that you don't have to refine that over time with the Awake team, is something that would help. That's not a criticism of Awake. It's more just a lesson learned.
In terms of the solution's false positive rate, we're still working through it. We don't look at the console too much ourselves these days unless we need to run a particular query to answer a question. Normally, we just rely on the MNDR team to surface anything that needs escalation to us. In some ways we're still in an onboarding period. The MNDR team will raise some sort of alert, and some of them definitely warrant further investigation, which has been really helpful. That's helped us identify certain risky behaviors that users are engaging in, and remediate them. At other times, we continue to refine our SOP with them. They'll alert us of something suspicious and we'll say, "Oh, that's okay. We allow large uploads to Box." They're usually pretty good about just saying, "Yeah, we'll put that in as an exception."
When it comes to the solution moving away from traditional alerts and focusing our team on the entities that pose the highest risk, we haven't really seen that as much, ourselves, because we've been pretty hands-off and leaving it to the MNDR team to monitor the appliance. We looked at the appliance during the PoC process and have looked at it ourselves occasionally. But one of the things that's tricky about our deployment is that we also have it monitoring our guest network, where we do see a lot of high-risk devices that are clearly going into bad domains but, at the same time, it's our guest network so it's not something we actively police.
The combination of Awake's technology and human expertise within the MNDR service has been really good. We're pretty happy with Awake. It helps us sleep better at night because we know that there's another team out there helping to watch activities on our network.
Awake is a great solution to get started with, for getting that initial network visibility, especially with the MNDR team. It also seems like a great medium-maturity solution where you could have an enterprise that wants to roll off of the MNDR team and have more of an internal capability and an internal team monitoring and utilizing Awake. That would work too. That's where we're thinking we might go, eventually.
I'd give it an eight out of 10 overall. It provides a lot of value. There are a couple of rough edges that they're still working on and that we'd like to see improved, but it's definitely very useful to have in the toolbox.
Which deployment model are you using for this solution?
Which version of this solution are you currently using?