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.

The initial setup of the solution was mostly straightforward. The appliance setup was very easy. The AWS cloud node took a bit of work to get going. They had to have a tech connect in several times and reconfigure it and make some changes until it was working. That was the only hiccup we had. Since then, it has been running flawlessly.

The appliance took about half a day to set up, because I already had a bunch of the network configuration, routing and port configuration, already done before we hooked up the appliance. The AWS part took about two days because they had to make configuration changes.

The initial setup was straightforward, not complex, from when the box arrived to when it was installed, 

We are planning to pivot to visibility in our cloud landing zones. That's where we will brainstorm or whiteboard stuff that says, "Here's what we can see," and then what we do is say, "Okay, if this happens, I want to know about it." Afterwards, we'll come back to the Awake Security guys, and say, "Here's the stuff that we want you to alert us on," which is really around the compliance stuff. For example, you're not supposed to egress out Azure's Internet. Everything has to come back to us. But we find people have configured it incorrectly and are sending traffic out to the public Internet through Azure's egress. Once we have network visibility up there, we will get alerted when that stuff happens, stating, "Outbound egress traffic has been seen. Here is the host and where it was going." We can then go back and either stop it or talk to the person who set it up.

The initial setup was straightforward. If people have ever put something on a SPAN port before, it's just really a matter of understanding what parts of your network you want to focus on. I would say we spent one hour doing a whiteboard session with Awake and our networking team to decide what's the best place to set these devices to have the most visibility. Then we were up and running the same week.

Awake is one of those things you want to focus your most critical networks on. If you know where your critical data is, especially data that's meant to stay internal or segmented in some way, Awake is a really good way to help monitor those environments. Especially if you have environments where you might have devices that for whatever reason, you can't have a standard endpoint security approach with environments that might be used for research, testing, or things that are really meant to be black-box type environments.

Awake can give you visibility into areas that you typically wouldn't have. In our implementation strategy, we really looked and defined those areas and figured out, what would be the right placement of devices to give us the visibility of our most sensitive data.

The initial setup was pretty easy. They came in and deployed a server on site. We had to make sure that we had the right VLANs exposed to the server so that we could see all the traffic. The user interface was pretty straightforward, just a sign on and password to the server. 

It was pretty intuitive to look at the different threat pictures that they had on the site. It automatically populates the most concerning ones at the top, so I adapted to it very quickly. The search features were pretty good. When I wasn't seeing what I needed to on the automated displays, I could use the menu to clip through a device or just look for a domain or for something that I knew might be concerning. For one incident, when I was trying to find a vendor who had an issue at their shop and I knew they had visited us, I just searched for their domain in our environment. It popped up and it showed me their device pretty quickly. It was a five-minute turnaround, which typically would have taken me a whole lot longer.

There was about a day of install and then about another day of initial setup. Then there was a little bit of tweaking we had to do when we weren't seeing all of the traffic that we thought we should be seeing, but that was on our end. That was just a matter of working with their team to tune the deployment for the server.

For our implementation strategy, we just connected to a SPAN port on our exit router at our main facility. Then we had to tune it to make sure all the VLANs that we had internally were going through that SPAN port. We had to set up a server, and we set it up in our server rack; we happened to have room which was nice. It only took up one or two U's. It wasn't very big.

Initially, to deploy it, I needed my IT staff and it took one network engineer. To maintain is really nothing. It's me using the system. Everything else has been remotely controlled by Awake, so there's been no need for us to interface with it, once deployed.

The initial setup was pretty straightforward. We were up and running fairly quickly. We knew how to do SPAN and TAP ports and I liked their integration with Arista which provides TAPs. That makes it an all-in-one solution now.

Our proof of concept took a couple of months and I liked the way they worked with us. We do a lot of due diligence before we make a purchase. They were very flexible and worked through lots of scenarios with us before we actually made the purchase. The company is very good to work with. It wasn't as though it was a challenge to set up. It was really just getting to know all the aspects of the product and feeling comfortable. There were no high-pressure sales. They were committed to helping us get the right solution for us.

It was mostly implemented as a result of the PoC. We then had to make sure that we had enough storage to store enough packet captures and to make sure it was in the right networks and was giving us the right visibility. Because of the way we've got to deploy, there is a lot of duplication in traffic between the various TAPs, so doing deduplication is a challenge sometimes.

There's definitely a learning period where you have to help them understand your environment and that's not something that you can outsource. You definitely have to have staff on the inside that knows what's important to you and what's not. What a false positive is will vary drastically between an environment like ours, which is an academic environment at a university, and a locked-down corporate environment at a financial institution. Everything they flag is interesting. It's not necessarily a false positive or not, until we think about who the user is that they're flagging. If it's a student doing something, that's a very different scenario from an executive doing it, for example.

Training their threat-hunting analysts is really the important part of any threat-hunting operation. They need to know how the customer's environment works and what the network looks like; not just what IP ranges are out there but what users are doing. Having all of that data in their own playbook is the secret sauce for success for any company and Awake did a good job of that. They really dug into understanding our environment and assisted us in implementation of this product from the get-go. There's always going to be a learning process for any customer, but they really helped walk us through the process.

On the admin side, the users of the solution are the five people on my team. They are all security engineers.

The initial setup was very straightforward. They shipped us the device. They sent us an engineer to work onsite. We already had a network TAP port configured, which they plugged in. Then, the configuration and data normalization was all handled by Awake. There was very little to no effort other than by the Awake engineer who came to our data center.

It took one day to physically deploy and a week for normalization of data. 

The initial setup was extremely straightforward. Basically, we just plugged it in and it ran. It's an appliance, so racking is what actually took the longest. It took approximately an hour, at most.

We first started deploying it on the edge, as a PoC. We deployed it for traffic entering and exiting our network, on the edge. Then we expanded it out to traffic that's moving laterally.

The initial setup was very straightforward and easy, almost plug-and-play. We already had everything set up on our end, network-wise. We already use SPAN ports and all they did was send us the preconfigured appliance and we plugged it in. They didn't even have to come onsite for that. Compared to some other solutions that we looked at, it was extremely simple.

Because we already had things in place it took us about one hour to get started. After a couple of weeks for the appliance looking through our live network data, we start receiving usable intel.

We sent the MNDR team a list of our key high-value assets that we wanted them to pay special attention to, and we sent them a list of all of the normal communication traffic that should be seen on the network, but which is not anything that we want to be alerted on. After that, we worked with them to remove some of the alerts that were repeatable, and that were not really relevant. After a couple of months of fine-tuning—not continuous, just as it came up—we got to a place where we just get one or two alerts a week, and they're valuable. That's been the situation for the last several months. We get all the information from them, what's happening and why, and if it's something that we need to take care of we do it immediately. That's one of the really big pluses: It's valuable information. In addition, the summary of the case tells us why is something happening and gives us enough information that we can remedy it immediately. Now the alerts we get are mostly for unusual but expected traffic. This gives us an opportunity to see that the appliance registers it and that if the same traffic were not expected or approved, we would know about it.

The initial setup was very easy. It's a web-based GUI. It's like an application. I didn't have to build anything. All of the algorithms are built into the tech itself on the back end. Once you get traffic going through a TAP or a SPAN port, you send that traffic to the appliance and the appliance does all the work for you.

The deployment took less than a week.

Our implementation strategy was to find our core switches, run the SPAN port off those switches, and send that duplicated traffic to the appliance.

Here is how straightforward the initial setup was. I got the device in October, which is fourth quarter for us and extremely busy. The Awake team wanted to fly in to do the setup. I told them that it was not going to work due to the timing and logistics. So, they shipped out the box. My team just put it in a rack and plugged it into the SPAN port, then we were done.

That was the entire setup. It is an appliance. All it requires is a Network Tap or SPAN port. We plugged the interface in, gave it a public side interface, and the Awake team did the final config remotely, then we were up and running in under two hours. That includes the rack time.

We had several meetings with Awake in terms of understanding our environment:

• Where it was best to place the sensors.
• What size sensors would we need.
• What type of use cases I was looking for.
• What were my pain points.
• What kept me up at night before we even embarked to the contract signing.

The initial setup is easy. You put Arista devices in the network as normal devices, and the VLAN traffic is passing on it. It requires two people to complete the process and takes a maximum of a day.