What is our primary use case?
It is a monitoring solution and network, because many times what we see is circuit oversaturation. Then, we want to know why and where it is coming from.
We were using Stealthwatch before the upgrade, since it came out. We have a good partnership with Cisco. We have NAS engineers. We have a quarterly meeting with Cisco. Generally, when they come out with a new solution, like when Stopwatch first came out, we jump on board. Therefore, we have been with it for awhile.
How has it helped my organization?
Our company is global and has various manufacturing plants over the globe along with branches. What we have found from a productivity policing perspective is we have had some of these locations abuse their on-net circuit. They will put it on Netflix and go watch movies when they are not supposed to, and we could not stop it. Unfortunately, we did not know what was going on. In the past, what we used to do was live and work with it. Thus, the company increased the circuit, and we were spending more, not knowing why.
When Stealthwatch finally came in, we were able to look into that pocket and flow, saying, "They are going to Facebook. They are going to YouTube. They are going to Netflix."
Based on other solutions that we had in place (Sourcefire, etc.), we were able to block the center accessing these type of features and apps. This brought down the circuit utilization significantly, then we were able to recoup costs. It saved a lot of money bringing down the circuit. Now, it is not abused anymore.
What is most valuable?
Visibility. The ability to look East and West. To see what is passing through your circuits, where it is coming from, and how big it is. This is pretty key for us. It is the network.
From a security standpoint, it is seeing pockets as well. Visibility is very key for us.
What needs improvement?
In the last year or two, we have been working with our Cisco NAS engineers to improve our security posturing. It is more our being proactive rather than reactive. While Stealthwatch and Lancope have this ability to look inside and give you visibility (a great feature), follow-up is the rule. We would like filters that you can put into place to tap onto certain types of behaviors, alerts out, and/or hopefully a block. This is sort of what we are looking for.
I might be speaking too early, because we are not down this path yet. We know the feature set is there, we just do not know yet how to achieve it. That is proactive rather than more reactive.
For Lancope Stealthwatch, we would like to see it more on the ASA Firewall platform. While this might already be available, this is more a failing of Cisco to inform us if it is there. For example:
- Are we on the right or wrong version of the code?
- What does the code look like?
- Are we are really looking at firewalls? Or is it more about the foundation and route switches that we are seeing?
It is about visibility.
For how long have I used the solution?
Three to five years.
What do I think about the stability of the solution?
It has been pretty stable. The deployment is the SNC which is located in our headquarters. Then, you have collectors and sensors which are sitting out there in our various eye pop points: East and West points out the door. The sensor sits on the standpoint, therefore it sees everything. The collector, you point to it, and it has been pretty stable in that regard.
Previously, the one thing which drove us crazy about the product was it seemed to be pretty locked on certain versions of Java. Now, it appears to have been improved. Thus, we are very happy with that.
In terms of improvement overall, we would like to see less reliance on Java and possibly a self-contained REST API package, either client or web-based would be nice rather than locally in Java. This would be a nice feature set.
Integration would be nice too. We are a pretty big Cisco shop. From ICE to our WCs. We are growing while we are looking at other products and solutions out there. Those solutions being FireEye or Palo Alto. Is there an integration where maybe East-West Lancope can see this type of traffic, then send updates and work lists with other products to say, "Block this as this is bad," other than the blocking point being Stealthwatch?
I understand Cisco has AMP Threat Grid. This is their ecosystem, and it is supposed to coordinate and work together in making the setup easy.
Self-pushes to the cloud, as long as your Cisco-based products report to the same cloud point, then you are all sharing data that way. That is still very Cisco-centric. It would be nice to see a little bit more integration with Palo Alto, FireEye, and VScanner, therefore not all being Cisco-based.
What do I think about the scalability of the solution?
For scalability, we probably want to see more NetFlow availability in other infrastructure products. We know it is there in routers, switches, and foundation. We know we can send it to the box. These are our current questions about NetFlow expansion:
- What about firewalls? Where does Cisco stands today on NetFlow or in the future for firewalls?
- Is there NetFlow on SPD? I don't know.
- Are we doing NetFlow on ASA today? Our company is not.
I do not think it is ready yet, or stable, and expanding NetFlow would be huge.
How are customer service and technical support?
Generally, when we do something with Lancope or Stealthwatch, either we play with the interface ourselves or we use our NAS engineer. I do not think there has been a situation where we looked for support on a tech case unless there is something really wrong. We have possibly had to contact them one time because of a bad disc.
Which solution did I use previously and why did I switch?
We used Riverbed, and it is probably still around as some people can't let go of their old tools.
When we saw what Lancope can do, not just from a visibility perspective, but from a network and security perspective, we jumped on board. Having security tied to the product is what really made it win out. We jumped in all the way. We spent close to a million, because there was a shared infrastructure between two companies. Every eye pop that we bring up or upgrade, Stealthwatch is there. We ensure it is there.
How was the initial setup?
It was pretty straightforward. Once you get the template down, you get to the eye pop or an egress point, then you need one sensor. Deployment is easy.
What's my experience with pricing, setup cost, and licensing?
Today, the company is part of the big Cisco ELA, and it is a la carte. We can get orders for whatever we want. At the end of the day, we have to pay for it in one big expense, but that is fine. We are okay with that.
One of the things which bugs me about Lancope is the licensing. We understand how its licensing works. Our problem is when we bought and purchased most of these Lancope devices, we did so with our sister company. We bought a ton of product. Somewhere within the purchase and distribution, licensing got mixed up. This is all on Cisco, and it is their responsibility. They allotted some of our sister company's equipment to us, and some of ours to them. To date, they have never been able to fix it. We still see this license issue pop up on our screen.
NetFlow is very expensive.
Which other solutions did I evaluate?
The only other option was the one we were using at the time, which may not even be comparable because of visibility, and that was Riverbed. Riverbed was extremely expensive.
Stealthwatch came out, and we jumped on board. It was not only cost alone that made us go with it. It was security which pushed us over the edge. The possibility of seeing in the packet these potentially proactive measures; things you can do to see patterns. The features were what won out.
What other advice do I have?
Come up with a template, then choose a center, choose a region, choose a plant, etc. Figure out how you want the deployment to go, then replicate it. Turn it into some sort of kit. As you stand up more places, or you deploy to other places, it will follow that template, then you are set and done.
This also extends to the config file, which is a bit more problematic. Depending on how large you are (we are very large), you do not always have the same model number of router. For example, we could have 1002X, 1001, and 1002X. They do not always align in terms of what that NetFlow configuration looks like. Some people put NetFlow on a switch.
Make sure that you are aware of that and you have the best template you can. Get your ducks in a row before you deploy, or else it is going to extend your deployment.
- Visibility is key.
- Security is also key.
- Being able to drill down into a center's utilization, then create reports based on it.
- Ease of deployment, once you get your ducks in a row.
Con: Reliance on Java. Get away from that.
If they can make this product more web-based, that would be amazing. I do not know the feasibility of that, but it seems like everything is going towards that direction anyway. The sooner Cisco can make use of the app rather than Java, the better.