What is our primary use case?
Our primary use case for Threat Stack comes from the fact that we are a smaller company and we don't have dedicated security resources. The biggest thing we need is auditing logs and the agent on all of our machines, and then using their SecOps program to help us filter and analyze that data, because we obviously don't have the manpower to do that. So our biggest use case is collecting all the data, having them there to watch our backs and to help give us recommendations on what we can fix, and to help us in case there is an incident, where they can help us track everything.
How has it helped my organization?
One of the ways they've improved the way our organization functions is that when we first signed up with Threat Stack, we were just using password authentication. Managing 70 servers with passwords is terrible. One of the first things they noticed and that we collaborated on was that we needed to start automating some of these logins and actually knowing who was on the box, so it wouldn't always show up as the same user. We needed to disable password authentication, which makes it a lot easier to deal with search certificates. It was basic stuff that I already knew.
Then they pushed us in the direction of automating that, removing the human element from it. We've been moving forward with Chef to automate all of that so I can get rid of the password authentication on all of our servers. That's just one code-push and all the servers update and I don't have to worry about it.
If I lose an employee, I remove their key from all the servers via Chef and they can't get into any of our boxes. If I need to redeploy an SSL certificate to our boxes, it's all done through Chef. That's been the biggest thing, their partnering with us and helping us identify ways to automate and make that better.
They've also helped with a couple of security audits that we've had and that has been very helpful.
The other positive changes are better insight into security, so when something happens it's not just, "Oh we had a security incident," or, "I've seen a tech blog that says there's a vulnerability in this version of Nginx. Which of my servers have that?" They take care of all that for me.
Also, getting the alerts in your face - we've integrated with Slack - so the dev team gets a notification every time a vulnerability is found or something is off. We can then check if someone really did that in our AWS account: Did somebody really mean to do that on our server? And then we can address the issue that way.
Rules give us more visibility and control over what's being triggered and that's been super helpful. I don't have the time to go in there and create those rules. So instead, if we do something that's out of the norm - something we're allowing security-wise that we probably shouldn't, but we're going to address it in the future - they'll contact us, they'll reach out to us as soon as they see something as an anomaly and say, "Hey, did you mean to do this?" We can then say, "Yeah, we did," and then they'll help us configure those rules to suppress them for a limited amount of time until we can resolve the issue, so we're not inundated by non-useful alerts.
In terms of cloud infrastructure, the biggest thing is the fact that they do connect with our AWS account and they let us know which boxes are and are not running the agent. They give us details on that. That's the biggest insight they've given there. That's allowing me to see which servers I have my agent on and which ones I don't. I can get a quick glance at my weak points and servers that I need to either migrate over or get rid of.
We have also seen a measurable decrease in the meantime to remediation in the sense that before, we wouldn't have even been able to detect and then get to the remediation. The remediation wasn't even happening. Now, we're actually alerted to and can start working the security issues. Before, we never would have known, so that's quite the improvement. It's really hard to quantify because we didn't have a good process. We were oblivious to vulnerabilities.
It has absolutely cut down the time to investigate potential attacks because it tells us immediately via Slack. We have a link, we click the link, we open Threat Stack, and it takes us right to the events we need to know about. That's been just awesome. In terms of time saved, to go in and dig through the servers and find all the logs, it probably saves 45 minutes to two hours per incident, depending on how impacting it is. We get a handful of alerts a week that we have to deal with, so we're saving a couple of hours a couple of times a week. Obviously, partnering with Threat Stack and implementing Chef makes all of that a lot faster. If you take into account all of that, we're saving oodles of time. If we actually had to go patch every box manually without Chef - which we got because of Threat Stack... That's saving a boatload of time, because of their recommendation and going through the security measurements.
What is most valuable?
The most valuable feature is the SecOps because they have our back and they help us with the reports. We jump on calls monthly to set goals and roadmaps internally for how we can secure our platform more.
Their SecOps program is absolutely amazing when you do not have a dedicated resource for security. Currently, we have 57 servers with the Threat Stack agent. We have about 70 servers in total. When you get to that point and you're running microservices, there's no good way to have all that data coming in from all those servers and have a system. The Threat Stack agent is providing the data. But even if we have the data, I have no time or expertise to know exactly what to look for in a log and what should alert me. Whereas their SecOps program is experienced, they know what to look for, they can continually adjust and look at the accounts. They can understand our behavior and know that something that doesn't look good is okay or we're allowing it, and then they can filter back those notifications.
It's like having an extension of your team. And then, it grows with you. If I were to hire somebody tomorrow, one security guy is not enough, but that person could directly work with the SecOps program and get up to speed, and then start taking over some of the manual toggles. And then eventually, in a year or however long, we could phase out the SecOps program. Or we could decide, no, we're not going to do that, we're just going to continue to leverage it and not built out an internal security team. The flexibility of it is just amazing.
What needs improvement?
They could give a few more insights into security groups and recommendations on how to be more effective. That's getting more into the AWS environment, specifically. I'm not sure if that's Threat Stack's plan or not, but I would like them to help us be efficient about how we're setting up security groups. They could recommend separation of VPCs and the like - really dig into our architecture. I haven't seen a whole lot of that and I think that's something that, right off the bat, could have made us smarter.
Even as part of the SecOps Program, that could be helpful; a quick analysis. They're analyzing our whole infrastructure and saying, "You have one VPC and that doesn't make a lot of sense, that should be multiple VPCs and here's why." The architecture of the servers in whatever cloud-hosting provider you're on could be helpful.
Other than that, they should continue to expand on their notifications and on what's a vulnerability. They do a great job of that and we want them to continue to do that.
It would be cool, since the agent is already deployed and they know about the server, they know the IP address, and they know what vulnerability is there, for them to test the vulnerability and see if they can actually exploit it. Or, once we patch it, they could double-check that it can't be. I don't know how hard that would be to build. Thinking on it off the top off my head, it could be a little challenging but it could also be highly interesting.
It would also be great if we could test a couple of other features like hammering a server with 100 login attempts and see what happens. Real test scenarios could be really helpful. That is probably more something close to what they do with the SOC 2 audit or the report. But more visualization of that, being able to test things out on our infrastructure to make sure we can or can't hit this box could be interesting.
For how long have I used the solution?
What do I think about the stability of the solution?
The stability has been great, we don't have any issues with Threat Stack running away with resources or causing any issues on our boxes. That's been very nice.
What do I think about the scalability of the solution?
Scaling is super-easy. Now that we're using Chef, installing it is a breeze. I would see no problem in scalability.
The only issue I might see is moving over to ECS and Kubernetes and any differences we might have to do in our configuration to make that be effective. But that's unknown territory. Currently, everything that we're doing is perfectly scalable to as many servers as we need.
How are customer service and support?
It's hard for me to evaluate their technical support because I've only had one issue and it was just a question on the difference between "investigate" and "monitor." It wasn't really a technical support question.
I did have one box that was not reporting information for a bit, and it was as simple as just removing the agent and reinstalling. That process was super-simple and they helped me on chat in two seconds. I probably could've just found it on their FAQ, but they actually helped me live. I've only had to deal with them once and things were really good.
Which solution did I use previously and why did I switch?
The SecOps program was the big seller to me, the fact that we would have their help and their support, especially at the time of an incident. That was the biggest deciding factor. In addition, the fact that their agent was super-easy to set up and get going, and the pricing too. The pricing was reasonable for the agent without the SecOps.
One of the other companies was similar. They gave you the SecOps-type deal, but it was like $100 per agent. They took that SecOps and bundled it in. But having the ability to stop the SecOps if we got there and then just pay a cheaper price per agent was very ideal to us because eventually, we probably do want to have an in-house security team. That also helped a lot.
How was the initial setup?
Very straightforward, the initial setup was quite amazing. Their installation of the agent is really slick and easy, and the data reporting back was great. We had an initial call. I don't know if everyone gets the amount of help we had at first, or if that was because we have the SecOps program, but getting our account tweaked to a level where we were okay with the number of alerts was really smooth.
The tuning process was great. We actually had a talk over specifics. They would say, "This is the behavior that we see that is weird or not normal." That allowed us to go back and say, "Oh yeah, we do tweak this file every so often, so we need to ignore that file because we are going to be changing it." It was great. There was a really good dialogue, really good back-and-forth. They gave us some homework items that we could go look into and figure out why things were happening, and then we could get back with them and tweak those alerts. That was very helpful.
We were deployed relatively quickly. It didn't take much longer than a week to get all the agents installed. Then, once they were set up, we were on a call the next week to get everything dialed in so that everything was working perfectly. It was about a week to get all this stuff set up and another week to go through and tune everything.
For our implementation strategy, we tested it on a couple of boxes just to makes sure there wasn't going to be any weird load or any interference with any our production applications. We ran that for a little bit of time. We had the demo agent for a week or two and then we went up for the full rollout. Once we had decided that it wasn't going to interfere or cause any problems, and it was going to give us what we needed, we rolled out the servers over the next week. It was me, and, because we did not have Chef at the time, I manually went in and installed it on all of our servers and then added it to documentation. As we added new servers we could make sure that Threat Stack was installed. That was it from our part.
Then we went to the tuning call and had that little bit of back-and-forth. We assigned a few people to go investigate some of the issues that were going on in our servers to figure out if they were anticipated behavior or should not have been happening.
What about the implementation team?
What was our ROI?
ROI is also hard to quantify. We have definitely gained business having Threat Stack. Being able to check some boxes and having an intrusion-detection service is probably where we've seen the biggest increase in revenue.
As far as development time goes, we weren't spending a lot of time on security until we got Threat Stack. So that's more of an investment.
It's hard to say how many deals we have won specifically because of Threat Stack security. We don't really have a return on investment because we didn't have a ton of security engineers that were wasting a ton of time.
What it's given us is way better security posture, way better answers to our clients. We can be proactive about security now and we can start that conversation, rather than being embarrassed to start that conversation. It's definitely gotten us into a lot more revenue opportunities. Had we not had Threat Stack, we could have been eliminated from many conversations. It's just hard to say exactly how many of them.
What's my experience with pricing, setup cost, and licensing?
What we're paying now is somewhere around $15 to $20 per agent per month, if I recall correctly. The other cost we have is SecOps.
Which other solutions did I evaluate?
We were looking at several different security companies. We were talking to a company called Armor. We were using Datadog for some of it, for what they give you out-of-the-box. There was one more that we were looking at but I can't remember what it was off the top of my head.
What other advice do I have?
I would advise, if you have the funding, that you have a security team. But if you're not going to dump resources into security, you're not going to have a full-on security team, the SecOps program of Threat Stack is amazing. It's so much better than not doing anything, if you're starting out as a startup. A SecOps program that grows with you could be helpful for some of these young startups.
If you currently don't have a security team, you need to get Threat Stack yesterday. There's no excuse to not have it at this point. It's not that large of a cost and the ramifications of not having it are that you may not have a business. If you're just not paying attention and you lose a bunch of sensitive customer data, or something of that nature, and you have no way to even get any answers about what was compromised or when, you're just in the dark. At minimum, you should have the agent, and I think the SecOps program is a no-brainer as well.
So far I've been very pleased with their ability to pull in the data. I've been waiting for their Windows agent. I'm not sure if it's out yet. 'We have legacy Windows servers, but one of our main goals is to kill all of our Windows servers. We might beat them to that, because I know they're testing it; it might be in the wild now. So that was one downside, but everything else, being able to hook right into my AWS was awesome and installing the agent is super-slick.
From what I understand, Threat Stack for container and Kubernetes monitoring is really good, but we're not doing any container or Kubernetes yet. We're looking at moving to ECS at some point, so we did have that conversation initially to make sure it wouldn't be an issue. But we're just not there yet. From what I understand it works out really well and behaves very similarly to having the agent on a regular EC2 box.
We haven't used Threat Stack as part of a SOC 2 audit but we would like to do that sooner rather than later. We're trying to get Chef up on all of our boxes and then we do want to get a SOC 2 audit, so we can have that on file and continue to run those. But we have not done so yet.
For maintenance, it's just me. I do everything and it's not my full-time job either. It only takes about half a person to run it. The other side of that, obviously, is making the system more autonomous, and that is harder. But as far as just managing Threat Stack, it's not very difficult to manage. It's a work-in-progress to get things automated and the cool thing is that we have a partner there and can make progress cycles. The reports we get are very detailed on where we're at and then the CEO can set either more aggressive or less aggressive goals, depending on where he wants to be from a security standpoint. That gives us a path and we know what we need to do, which is very helpful.
I have a couple of developers who constantly watch the alerts with me, two team leads. If one of them adds a user, deletes a user, or changes access on AWS, we get a Slack alert right away. All three of us try to keep each other honest and make sure we're the ones actually doing those things. We had a developer in Guatemala for a couple of months. He tried to do something inv AWS and it kicked a Threat Stack alert down to us. The other team knew right away. It was interesting because it was from Guatemala where we normally don't have anyone log in. That was like a test of the system. So we respond to those kinds of things very quickly. Three of us keep an eye on it and make sure things are always going as well as they can.
In terms of usage, security is a main focus ours and it was a big 2018/2019 objective that we're still working on and making pretty good headway. Threat Stack is the cornerstone of that. We want to continue to get to the point where Chef is on every one of our servers. Currently we're at about 60 percent with Chef. We want to finish that out and then we should have no vulnerabilities. Then, any time a vulnerability comes up, we can start treating that just like any other request to fix a vulnerability, and it's going to be done in Chef. That's how we plan to roll it out and to continue to make our security posture as good as possible.
I would rate Threat Stack a solid eight out of ten. A ten is hard to get. I don't like to give a ten easily. A ten would require a little more touch from them. In the last quarter we had a couple of reports come out where there wasn't a phone call. There was just the email and a note saying, "Hey, if you need anything, reach out." If they forced that phone call - and I understand there's a sensitivity there, they don't want to be too bothersome - then on my side it would have been, "Oh yeah, I have to have this call and I have to tell them that I didn't meet the initiative that we wanted to meet at this point." As an email it was like, "Oh yeah, put that under the Threat Stack folder," and I'm never going to reply to it. Holding me more accountable would be better. It's not really their job, but I feel that by touching base and making sure that our objectives haven't changed - having that phone call - could help, instead of just "Reach out if you need us."
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
