Threat Stack Cloud Security Platform Reviews

We're using Threat Stack for multiple purposes. We use it for file integrity management and we also use it as an intrusion detector, using it to monitor the interactive sessions on our Linux machines. We also do CloudTrail analysis and alerting.

We have about 210 microservices that make up our product. There are over 140 developers who have access to production, and they can troubleshoot but they're not allowed to make changes. We have to give them enough access to do their troubleshooting while ensuring that they aren't making any changes to the production system. The only way to do that is to monitor every command that they run in production and alert on those commands that are suspicious. It's working to ensure our developers are doing the right thing.

It can also provide a warning that someone from the outside may have compromised a machine. If somebody runs a suspicious command, like whoami or netcat or curl, or any of those kinds of commands that you don't expect, we're immediately alerted. It's a really great tool for that, and we can specify really granular rules.

The things that our developers are normally allowed to do and that we expect to happen, those aren't going to alert somebody. But the things that we don't expect to see in a production environment, those will alert somebody, and we'll move very quickly on them.

The way Threat Stack has improved our organization is directly related to how our production environment works and how we monitor it. The improvement is that we are able to get PCI certification. We use Threat Stack as a compensating control for PCI. We do have developers who have access to our production environment, so we don't have the traditional separation of duties that PCI would like, where the developers who write the code don't have access to production. But we're able to show the compensating control, that we monitor everything that happens in production and that there are no changes made in production by these developers. Threat Stack gives us that ability to implement a compensating control and show it. We were able to get PCI with this control.

The rules definitely give us more visibility and control over what's being triggered. We are able to monitor our environment and see what is normal. When we first installed Threat Stack, we obviously had a lot of alerts. Over time we have been able to monitor and see which of those things is normal. For example, which alerts happen because of automation, automated things that are happening in the environment and that trigger expected alerts? We don't need to see these as alerts. These are expected actions, they're authorized and not caused by users. They wouldn't be caused by a bad actor. They're just simply automation. We are able to write very granular alerts that look for that automation and no longer alert us on it, so we're able to cut down the alerts to a manageable level.

In terms of our cloud infrastructure, one of the things that we get from it is that we now have a baseline of normal. What do we expect to see? What are normal operations? From a security standpoint, what's going on that is the average, that we expect, and what is an outlier? This is one of the tools that allows us to say, "Okay, this is our normal baseline, these things are outliers." And even if they don't reach the alert level of a Sev 1, they're still outliers that we're logging as Sev 2 and Sev 3, and we're still looking at those every day just to see what patterns are changing.

In addition, we use Threat Stack for SOC 2 auditing and it saves us time for the same reason I noted about the separation of duties. It's a tool that we use in the SOC products to show how we're monitoring what happens in our production environment. We use it as a compensating control for the lack of a separation of duties.

Finally, Threat Stack has cut down on the time needed to investigate potential attacks by about 75 percent.  It's much faster now.

The number-one feature is the monitoring of interactive sessions on our Linux machines. We run an immutable environment, so that nothing is allowed to be changed in production. All changes have to happen in development, and then new systems are built in production. The only thing that is allowed in production is troubleshooting, find out what the issue is, but then it has to be fixed in development. We're constantly monitoring to make sure that no one is violating that. Threat Stack is what allows us to do that.

The solution's ability to consume alerts and data in third-party tools, via APIs or via export into S3 buckets, is working very well. We use the API to send monitoring to PagerDuty. And we've started using the API into other systems. We have it going out to a Slack channel, we've got some going into our automation. We're doing more and more with the alerting now. We're working directly with Threat Stack to use their APIs as they've recently been expanded. 

We're logging into S3 to do a little more in-depth research on what our alerts are, and we're also consuming CloudTrail events, which is a fairly recent update to Threat Stack, enabling us to alert on suspicious activity in CloudTrail.

The API - which has grown quite a bit, so we're still learning it and I can't say whether it still needs improvement - was an area that had been needing it. They have just recently come out with new improvements. 

I'm looking forward to their code analysis, which is coming out as a result of an acquisition they made.

It's been rock-solid. We've never had an issue with Threat Stack.

No issues with the scalability. We run over 5,000 production instances on it.

We have very few users. There are only seven people who have access to the Threat Stack console and they're all security engineers.

We have used Threat Stack's technical support and they've been great. We contact Threat Stack and we hear back pretty much immediately.

We used Trend Micro Deep Security. The issue was a problem in the agent that goes on the servers that was causing our servers to crash. It happened a couple of times and the support wasn't what we wanted, so we decided to change products. We couldn't handle that kind of outage.

I can't say there has been a decrease in the mean time to remediation because it's not really an apples-to-apples comparison. Trend Micro had different capabilities.

The setup was very straightforward. The rules are easy to write. It's common language, it's not anything arcane where you have to learn how to write in their language.

The initial deployment only took us a couple of weeks. I'd say that we were comfortable with it within a couple of months, as far as our base-level tuning. We're tuning it forever, constantly reanalyzing our environment and making tweaks to it.

Our implementation strategy was that we deployed it in our production environment and simply monitored with the stock rule set that they gave us. Then we started trimming it from there based on what we saw as normal in our environment. We started writing granular rule sets based on the alerting that we were getting. We were also patching it with another tool that we have called Sumo Logic, where we do logging and alerting. We were using that to get some of the information on what we wanted to see and creating queries based on that.

It was built with two people, because that's all that our security team was at the time that we deployed this. We currently manage it with five people, they're all security engineers.

Tuning is really simple. It's a matter of monitoring the alerts that come in, whether they're Sev 1 through Sev 3, and determining whether they are normal, expected, and part of the baseline, and then filtering them out. Or, if they're something that is not expected, or something we want to know about, we increase the severity to a higher level so that they're treated differently. We have different actions for each of Severity 3, 2, or 1: page the engineer, email an on-call engineer immediately, or just send a daily wrap-up email. We're constantly looking at that to see if we want to change the actions.

We did the deployment ourselves.

We have seen return on investment but I can't come up with a number because of how much we've changed. When we had Trend Micro, we had only some 500 instances, and now we're at 5,000.

I honestly don't know what pricing would compare to, because there wasn't a whole lot on the market at the time. It came in cheaper than Trend Micro when we purchased it a few years ago. It seemed to me to be priced well.

We looked at was going on with open-source, with OSSEC, and doing it ourselves. That did not prove to be scalable.

The best way really to demo and implement is to deploy it with the standard rules that come with it and simply monitor the environment for about a month, just to get a baseline before going and adjusting rules and customizing.

We are growing. Our product grows 100 percent, year-over-year. That doesn't increase our instance size 100 percent, but we do grow. We are expecting to continually grow for quite some time.

We have multiple use cases of equal importance:

• endpoint security
• cloud platform monitoring 
• orchestration security.

The most important example of how it has improved our organization is that we had a security incident that I can't give you a lot of details around. But about two months, ago an attacker compromised an internet facing system. We were able to detect, analyze, and remediate that in less than 60 minutes, on a Saturday.

When an attack compromises a system it changes the configuration of that system. Being able to detect that immediately and take action on it in an extremely short period of time is unbelievably valuable and pretty much mandatory.

The rules definitely give us more visibility and control over what's being triggered. We demo a lot of different security tools, especially cloud-specific security tools. So far, Threat Stack is the only one that we have found that ties all the relevant pieces together, so that we can take action in a meaningful way. Every other security tool we've looked at is good at containers, or at Kubernetes, is good at AWS, or at instance monitoring. But nobody is good at tying all of those things together, and that's really where Threat Stack shines. They take endpoint security and these new technologies very seriously. That alone differentiates them from just about every other competitor in the market right now.

It has absolutely provided us with the ability to gain actionable insights into our cloud infrastructure. We use it as a configuration monitoring and alerting tool. The fact that we can tie 20 AWS accounts into a single view, or a single pane of glass, and monitor the security configurations of those 20 accounts in one setting, is just huge.

We have also used this solution as part of a SOC 2 audit, two years in a row, and it has saved us drastic amounts of time. Before Threat Stack, collecting endpoint evidence in, for instance, AWS configuration evidence, would take a team of three people about a month, in terms of total duration, not total time. Now, we're able to provide that evidence within an hour.

There has been a measurable decrease in the meantime to remediation, by 95 percent. It's a ridiculous level of change, I can't speak highly enough about it. When we had security incidents before, if we detected it - and that's "if" because we didn't have the same level of visibility - the remediation cycles could last weeks. The reason for that was trying to understand what the blast-radius of an attack was. It took a long time to figure that out because we were correlating information from multiple tools, trying to link data, and it turned into a big data problem that we had to solve very quickly. Each incident was different so the data sets were different. It was really hard to set up playbooks to do that quickly. But with Threat Stack, because we have so many different tech verticals already collated in one place, our ability to respond is drastically different than it used to be. It has also cut down the time to investigate potential attacks by the same amount, 95 percent.

The endpoint security monitoring, the AWS security monitoring, ties all of these things together in a way that we can make sense of data that, before, wasn't available or tied. For example, if we have a security event on an EC2 instance, we can correlate that to a security event on AWS on the management platform. 

The threat detection pieces of it are our most valuable resource, and right behind them is configuration monitoring. Those are the two highest risks to our environment. 

In terms of using this solution for container and Kubernetes monitoring, that's a pretty new feature and it's definitely coming along. I think they're very good at it right now, and they keep adding features, so we're pretty happy with that at the moment.

The tuning process is pretty straightforward. Their rule sets are easy to understand. The UI is set up in a way where it's really easy to modify false-positive alerting. It's one of the more low-stress tuning operations I've ever done, compared to other endpoint security products, or ITS-type engines.

The solution’s ability to consume alerts and data in third-party tools (via APIs and export into S3 buckets) is moderate. They have some work to do in that area. I'd like to see more on that side. I'd like to see much better reporting. The API does not mimic the features of the UI as far as reporting and pulling data out go. There's a big discrepancy there.

The other thing that would be really great - and I know this is something they might not want to get into as a business, but it's something I'd love to see - would be if we could bring in data from other tools, specifically AWS WAF. If we could bring in data from there, and include that with what they're already collecting, that would be a huge game-changer for us.

Finally, container vulnerability assessment is something they aren't doing right now.

It has been super-stable, we haven't had any downtime. We've had a couple of instances where agents stopped running, but that was because of interfering processes on an endpoint. They're like snowflakes, very unique circumstances. But stability has never been a problem.

It scales to whatever we want to go to.

Tech support is fantastic. We're a very advanced shop. We're not patting ourselves on the back, it's just that we find problems in products that a lot of other customers don't find. When we do have a problem, Threat Stack's response is immediate. They bring all hands on deck. They have even gone as far, in the past, as bringing their engineering staff, their development staff, to help solve problems in a quick way.

We replaced CloudWatch for AWS configuration management with Threat Stack.

The setup was very straightforward. It's built to run in the cloud so it doesn't require any infrastructure on our side. It's a very simple agent and its extremely easy to install. Even more importantly, it's wickedly simple to automate the deployment. They put a lot of thought into that when they designed the agent. One of the biggest problems we had with other vendors was that deploying was always a bit of a nightmare. With Threat Stack, it's ridiculously simple.

We were able to deploy to somewhere around 3,700 nodes in less than two weeks. Most of that time was writing the automation. The deployment itself took hours.

We use immutable infrastructure. So our implementation strategy was to include the Threat Stack agent installation into our initial instance configurations.

Return on investment with security tools is hard to gauge. It's not unique to us, but for some companies, security is a sales driver and we're definitely one of those companies. Having Threat Stack in place, being able to provide meaningful artifacts to our customers, has definitely shortened sale cycles for us.

Where we had to abstract ten different sets of data to create an artifact for an audit or customer review, we don't have to do that anymore. It's very easy for us to demonstrate our security controls. We've been able to pick up multi-million-dollar accounts from very large technology companies that have extremely strict security requirements because we have this tool in place.

It's too expensive, but I'm always going to say that. It is very expensive compared to some other products. The pricing is definitely high.

We did a demo with Twistlock but we never actually implemented it because we had a ton of problems with it. We used OSSEC for a long time, and Trend Micro on a previous iteration. We're so picky about the products we choose. We've demoed polls from Palo Alto, Aqua Security, and a bunch of others. I'm having trouble keeping track of all of them. Threat Stack is the one we keep coming back to.

We've gone with Threat Stack for many reasons. It ties together these multiple technology verticals in one pane of glass, and cross-correlates security across those verticals. That's super-important, I can't overemphasize that. That's a big differentiator, as are the ease of deployment, ease of management, the reliability, and support we get. We keep coming back to them because all of our other experiences have had very negative portions to them.

We're paying a lot of money for a product, so we don't want to have to spend more money on infrastructure to support the product. A lot of other vendors require us to build dedicated servers inside our networks. They don't deal well with multi-AWS-account businesses. And the biggest thing is that a lot of products we're seeing in the space are really geared towards enterprises that are going to the cloud for the first time; greenfield-type applications. Threat Stack is flexible enough that it really does well in an environment where a company is already cloud-native. We're SaaS company, our demands are very unique to the SaaS world. We've been on the cloud our entire life. Having a tool that can work within that paradigm, and not necessitate greenfielding everything is super-important.

Build very tight relationships with Threat Stack's sales, engineering, and onboarding teams. That is something that has saved us a good amount of pain. Also, spend a dramatic amount of time going through their documentation; really understand the product before you start deploying it.

We're using a combination of the 1.X and some of the 2.X agents. We're one of their more advanced, self-sufficient customers. We definitely do not buy any of their services.

It's only security and site reliability engineers who use the tool. We have 20 to 25 users. But that's for 3,700 endpoints and it's going to be close to 20,000 containers. Deployment and maintenance of Threat Stack require two people, security engineers. That's only for redundancy. I ran the product for about ten months by myself.

As our infrastructure grows, our usage of Threat Stack will grow with it.

It is a daily visibility and alerting tool for both general security as well as SOX compliance. We use it to monitor privilege escalation, access to our AWS environment, EC2 instances, spotting of EC2 instances, etc., as well as vulnerability and patch management.

We have the standard threat visibility dashboard and alerting platform and we also have their assisted service they launched mid last year, a monthly threat evaluation/vulnerability assessment which they send.

The capacity to respond to evidence requests from the SOX auditors has significantly improved because of this tool.

It has also provided us with the ability to gain actionable insight into our cloud infrastructure. We have a long list. The vulnerability and patch-management components allow us to see what our most severe and actionable items are for platform OS, our EC2 instances, our golden images. We're able to see what instances have the greatest need for assessment and remediation and we move down the list on those. Over time, that's going to substantially improve our overall security structure.

We're also seeing the ability to respond to things in real time, particularly Sev 1 Alerts. We don't have any delay. We get the alert, we can immediately jump in. We use Threat Stack to do some forensics on it, figure out what's actually going on, and resolve the situation very quickly. Fortunately, we've not had any true penetrations, but we've had things that have happened and we've been able to alert on those and make adjustments.

It's given us another 50 percent in terms of the time it takes for us to be aware of something. Threat Stack is a great tool for that because it makes you aware more quickly, as opposed to CloudWatch or CloudTrail. The time-to-awareness is significantly decreased because it's an alerting platform. By comparison, it's arduous to write rules that really apply well in CloudTrail or CloudWatch.

In terms of the time needed to investigate potential attacks, the data that's available in the single pane of glass probably knocks half the time off because we don't have to jump over to AWS. We've got it all there.

It has been quite helpful to have the daily alerts coming to my email, as well as the Sev 1 Alerts. Anything that pops a Sev 1 comes directly to my email. Most recently we started getting those monthly evaluations and that's definitely helped us with our overall security stack, as far as how we're dealing with things in AWS. The dailies have been most helpful. We just went through a SOX audit and those were pivotal.

We're using it on container to see when activity involving executables happens, and that's great. We're not using a Kubernetes at this stage.

As far as alerts go, we can write our own rules. I continue to tweak rules, modify rules, etc. That's a big deal for us so that we're getting relevant information, but not miss other information. It is fairly easy to tune. The ability to fine-tune rules and write new rules is very straightforward. It doesn't take much learning at all.

It certainly has a lot of capabilities and we're not using much of what it can do. That's something that, as we mature as an organization, we'll expand into. 

The one thing that we know they're working on, but we don't have through the tool, is the application layer. As we move to a serverless environment, with AWS Fargate or direct Lambda, that's where Threat Stack does not have the capacity to provide feed. Those are areas that it's blind to now, so that's the biggest area for improvement. They're currently looking at changing that with an acquisition, but as it stands right now, that's the only spot that I consider weak.

The stability of Threat Stack has been very good. I've had no impact from it being down when I needed it.

The issue for us was understanding how the scalability works, because we do have these bursts during Black Friday when we go about 30 or 40 average EC2 instances to several hundred. Once we figured out how to manage that, we found it scales brilliantly.

Their technical support is very good. I have found them to be extremely responsive and accurate. They've been excellent to work with.

I believe the only thing the company used before Threat Stack was the incumbent AWS logging: CloudWatch, CloudThreat, CloudTrail. The switch was made for the ability to have a single pane of glass to view all of the aggregate log information.

I was not part of the initial setup. I was secondary to that. It was already installed when I was hired. I helped configure and flush it out for full use. But it had already been installed and the primary Sarbanes-Oxley rules had been built.

My interaction with it was easy, but I would assume the setup was fairly straightforward because nobody came warning me that this was a complex tool.

My strategy was to take it from a purely compliance-alerting and rule tool and turn it into a more security-centric tool. I implemented additional rules that were specific to actual security threats and created actionable lists on those. We needed to start paying more attention to the vulnerability-management piece.

The ease of audit tracking for Sarbanes-Oxley audit was a dramatic change from last year. That's a key win. I don't know that it paid for itself there, but it certainly contributed to paying for itself there.

Pricing seems to be in line with the market structure. It's fine. There's not a problem with it. It seems to fit well within the current pricing structures that are out there.

One of things that was dropped here that I picked up and have been running with is that Threat Stack should be implemented and comprehensively applied to security for security's sake, as well as for compliance. It was initially bought here as a compliance tool to help with Sarbanes-Oxley. So a lot of the security stuff was ignored. If you are is looking at Threat Stack, you need to look at it as the comprehensive solution that it is. It can certainly be used very effectively for compliance elements. But it has excellent security elements.

We have a software security architect who utilizes it. I utilize it as the Director of Information Security. And our CIO utilizes it just for oversight to see what's going on. He doesn't have a lot of interaction with it. So we have two functional, active users of the tool. As far as maintenance goes, it's really the two of us. We do involve another member of the infrastructure team, an infrastructure developer, if we deploy agents to new EC2 instances that are not already golden-imaged with the instance, or we update images, or update the agents on the instances.

Regarding the capacity that Threat Stack has, we're probably using half of it. The goal is to certainly implement many other elements into Threat Stack and then cross-feed the Threat Stack data itself into other tools like SIEM for the enterprise side, so that we get correlation. The plan is to continue to maximize Threat Stack as our AWS primary visibility tool.

I would rate the product at seven out of ten. If they can solve that application layer side of it, it would take them up to a very solid nine.

Our primary use case is security.

It provides the security team with visibility into parts of the organization that were otherwise difficult to see into. By installing the agent we can get visibility into parts of our infrastructure that we otherwise didn't have access to and couldn't see.

The solution provides us with the ability to gain actionable insights into our cloud infrastructure. It gives us a lot of visibility into what's happening in our AWS accounts. The security team can monitor and provide oversight to the cloud operations team. For example, when new security groups are being created, or ingress and egress points are being created at the network layer, we can ensure that they've been documented, tested, approved, and that they have gone through change-control management; things of this nature which are required for, say, compliance purposes. We can detect and then ensure the controls are in place to close the whole loop of the change-control management process.

We develop a SecOps program around this solution. We're using this application to establish some of the controls as part of a SOC 2 audit, as part of a control environment, as well as PCI.

It is a fantastic tool that gives us a level of comfort knowing that there is not only something that's watching, something that can alert and detect, but also knowing that there's an outsourced operation center that can be an auxiliary part of our security team. That is super-helpful. Having their experience in the Amazon Web Services environment is really great because most of our operations are in Amazon Web Services.

We like the ability of the host security module to monitor the processes running on our servers to help us monitor activity. We want to make sure that there are no bad people on our machines. This has the ability to detect those bad people or bad processes on the machines.

The rules are really great. They give us more visibility and control over what's being triggered. There's a large set of rules that come out-of-the-box. We can customize them and we can create our own rules based on the traffic patterns that we see. The rules did take quite a bit of customization and configuration right off the bat because a lot of the way that we do the release of our code and products creates a significant amount of noise. The real signal, the security signal, would have been lost in all that noise. So we had to customize the rules fairly significantly in order to filter out that noise.

The user interface can be a little bit clunky at times. My enjoyment of the user interface is not 100 percent. We maintain multiple sites, a pre-production site and a production site in different parts of our business. I find myself switching between those sites fairly frequently and I lose track of where I'm at: Am I in the pre-production account or the production account? Sometimes that's a little discouraging. There's a lot of information that needs to be waded through, and the UI just isn't great. They do have a great API. The API has been helpful for us to use as a replacement in many cases for the UI. 

The reports aren't very good. We've automated the report generation via the API and replaced almost all the reports that they generate for us using API calls instead.

It has been fairly stable. We've had a few cases where we've internally knocked it over ourselves, but the software itself has been fairly stable.

We haven't had any scalability issues. It has been horizontally scalable for us and they seem to be able to handle our traffic. Our traffic patterns are fairly spiky, and even during high spikes they haven't seemed to be holding us back at all.

The technical support is excellent. We email them very frequently. I don't what they would call this level of support, but it's like post-sales support. We have a technical account representative and we email with this individual very frequently about issues that we're having: rule configuration, how to do X, Y, and Z. Once in a while, they'll escalate an issue to the tech support and in those cases tech support has been super-helpful as well. The two issues that have been escalated to tech support have been handled really quickly and really professionally.

We used basic auditd. It's an open-source auditing framework for the Linux environment. The main reason for switching to Threat Stack is that, while Threat Stack effectively does what auditd does, it gives you a user-interface around it. It gives you a way to view the data, to store the data, to search the data, to write an API around the information, and the ability to put controls and best practices around your AWS account. The auditd solution is there but you have to do a lot of heavy lifting on your own. With a very small security team with limited resources, it made a lot of sense for us economically.

It was a little tricky to bootstrap, it took a little time to get started. Once we did get started it leveled off really quickly.

There are two parts to the setup. There's the setup of the agent and the setup of the Amazon Web Services monitoring part. The AWS monitoring part was really easy. Our operations team found it to be really straightforward. There was a cloud formation stack that they executed against and it was really easy. 

The installation of the agent, as well, was fairly simple. However, it is installation of software into a production environment and that creates nervousness for operations teams in terms of stability and performance. Is it going to degrade the performance? Will it cause instability? We went through some significant performance testing, load testing, and actually had to work with their installation teams to get the configurations tuned to match our performance needs. 

Out-of-the-box, performance degradation was somewhere north of 15 percent and we had to make changes to the rules to get it down to around three percent performance loss.

The installation was actually fairly easy, but getting to the point where we could actually install and deploy broadly took us a little bit of time.

Our deployment took four to six weeks.

The implementation strategy took into consideration the fact that we have multiple accounts, a pre-production account and a production account. The pre-production account was where we did all the testing initially. We tested the service against the pre-production account for Amazon Web Services. We also installed it against some local Amazon instances and tried it out to see what would happen, and then worked with their team to get the assessment of the performance. 

We then worked on tuning and tweaking the rules and then started to work on a production strategy which was installation onto hundreds and hundreds of EC2 instances. Again, we started off fairly slowly, installing onto one instance, measuring and monitoring the performance degradation and working with them on resolving the performance degradation issues. We then did the production operations build-out through the operations flows. They did all that work and then we turned it on.

Once all that was on and enabled, we started to tweak the rule set, and tweaking the rule set took another two to three weeks of pretty solid time because of the way that we deploy our software, there are a lot of shell scripts and shell commands and privileged escalations that are happening to get the software deployed onto servers. Getting all of that stuff excluded out from the findings took quite a while.

The tuning process did take time. The way you deploy software will affect how much tuning you need to do. For example, if you have an immutable Kubernetes cluster, then it's very likely that you won't have to do any tuning at all because there won't be any commands or anything running that is of an abnormal nature. Anything that's happening in your cluster that Threat Stack is detecting would be of abnormal nature. It will be reporting those things and you want to know about them as soon as possible. The way it works isn't in that immutable type of environment. It's very much a case of our having these servers, we deploy new code onto them, and there are a lot of moving parts. It's detecting and responding to a lot of these different moving parts. We have to build into the rules to filter out those moving parts. Otherwise, the rules just become useless.

We did it internally.

I don't know that there's an ROI. We purchased the product that gives operations center oversight. We're basically replacing some FTE-equivalent in that budget pool. In security products, there's never really an ROI, although preventing one breach is like a return on investment.

I'm happy with the amount that we spend for the product that we get and the overall service that we get. It's not cheap, but I'm still happy with the spend.

We didn't evaluate too many other options. I had been talking to the Threat Stack team for some time and had known about the product, its features and functionality. We decided to jump in and make a purchase fairly quickly.

Understand the types of users and behaviors that you have in your environment and whether it's changing all the time or very static. If it's a highly static environment, Threat Stack can be a very easy-to-use, drop-in solution that is going to give you peace of mind. If it is a more complex environment that has a lot of moving parts with a lot of systems administrators logging on and running commands all day and all night, it's going to take you a little bit of time to tune the system to the point where you know what the baseline of activity is so that you know what the malicious behavior might be. So plan on having a little bit of time built into your schedule for that.

We're using their SaaS service.  Regarding the solution’s ability to consume alerts and data in third-party tools (via APIs and export into S3 buckets) we haven't used that feature yet. It is something that we're actively looking to do; and similarly for the container and Kubernetes monitoring.

In terms of MTTR, that wasn't the reason for the purchase of this product. The purchase of this product was to get visibility into all the different systems that we have and to know if and when we're being compromised. It wasn't to provide a lower MTTR.

It has probably increased the time to investigate potential attacks, in a somewhat perverse way, because we're actually investigating more stuff than we had before. We're taking a look at more items than we did before, so we're doing more work. By doing that, we're still on the up-slope of the learning curve and we haven't quite leveled off yet. I think that it will eventually level out.

There aren't many people using the solution day-to-day. We have three or four security operators using it day-to-day, looking at alerts coming through. But the operations team is basically waiting for us to say if there are any issues. It's really just the security team looking at it. In terms of deployment and maintenance, they are tasks that were done by somebody and then they moved on and did other things. There's nobody doing this full-time. They're not sitting there all day, every day, at the screen. We're using it when high-severity alerts come through.

We get automated, daily reports from the system. We review those via email and that's about it. We're not in the tool poking around, not very often. It's silently doing its thing in the background.

The product is being used across the enterprise. It's being used pretty much everywhere. We have one little pocket where it hasn't been deployed yet. But across all the different pieces of M&A, different acquisitions that we've made, it's on all of them except for one across our flagship product. We just have one more little pocket to get installed, when we have some operations resources, and then when that's done, it'll be fully deployed everywhere.

This product is a solid eight out of then. The basic core functionality is exceptional. I have a lot of faith and trust in it. The performance is good for what it does, meaning that it doesn't degrade the performance more than I would expect, given the types of things that it's expected to do. The only things that are pulling it down from a ten are the user-interface elements and the reporting which is a little bit weak. There's some room for it to grow and to get better, but otherwise, I think it's a pretty solid product.

Our primary use case is to validate our AWS configurations, as well as to provide endpoint protection to our hosts in the cloud. Our primary use of the tool is to gain actionable insights into our cloud infrastructure. The dashboard and daily audits of our environments give us a plan of action for items that we may need to remediate going forward, or for new resources which may need a configuration checkup.

Threat Stack allows us to quickly identify public AWS buckets across a large number of accounts, so we can validate what is within those public buckets and should be publicly accessible. That no buckets are being created incorrectly is probably a safe thing.

The ability to reconfigure alert rules allows us to ensure that what we are alerted on is a priority for us.

It provided valuable data in our recent SOC 2 type II audit, where it saved us time.

We enjoy the AWS Config audit within Threat Stack. This allows us to quickly score our AWS accounts against known, good configurations, then receive a letter grade which is easy to understand, as well as suggestions for plans to improve those scores and remediate issues.

I would like the following: 

• Further support of Windows endpoint agents or the introduction of support for Windows endpoint agents. 
• The ability to quickly templatize rule sets and share them.

We've had no issues with the stability or availability of the product.

Deployment and maintenance can be managed by a single party. In our company, we are leveraging somebody in the security team to manage it.

We have not hit any limits within the service. Talking with other customers, I have never run into anyone who has hit any form of service limit within Threat Stack.

We have approximately 12 users, which range from security, compliance, privacy, engineering, and development.

We are currently using Threat Stack across more than 20 AWS accounts and are beginning our deployment to several hundred hosts within the AWS system, nearly a thousand.

I used the technical support on limited occasions. They were timely and quickly got me to resolution.

The initial deployment was straightforward. It requires a simple key-pair configuration into AWS to gather the information that they need. Their endpoint agent deployment is done via script provided by Threat Stack.

The initial deployment was done in less than ten minutes.

Our original implementation strategy was to deploy Threat Stack into our production accounts to provide audit information as quickly.

We deployed it ourselves.

With Threat Stack, we quickly identified some AWS accounts which had services that would potentially be exposed and were able to remediate them prior to release of products.

We have seen a measurable decrease in the mean time to remediation.

We find the licensing and pricing very easy to understand and a good value for the services provided.

Purchase it as soon as you possibly can because the information it provides you is invaluable.

We tried a number of internal AWS tools, but that was all.

We went with Threat Stack because they provide the benchmarking against industry accepted known, good standards within the cloud. Their continuous audit and monitoring is something that we needed, along with their scoring overtime.

The tuning process is easy to use given the preconfigured rule sets which are offered and the flexibility of the API to create more rule sets. It is very easy to silence alerts that you may deem unnecessary in your environment.

It is my understanding that the Threat Stack API is pretty consumable, and if you want to do exports, you may.

We haven't had an incident where we needed to investigate a potential attack.

We will be using this solution for container and Kubernetes monitoring in the future. We do not currently use it for that, but it is one of the primary reasons we selected their endpoint protection, because of their support for containers and specifically Kubernetes.

The primary use case of Threat Stack, is the file integrity monitoring. If any change happens at the file level on the net server, then it should send us a report back.

Threat Stack is pretty easy tool because their integration with AWS instances and everything, that's easy. So you build up a Threat Stack server, if you go to their AWS instances one at a time and then later on, if a new instance gets added or removed, it will keep an eye on that. It acts as a traditional IPS, so whatever, when it is introduced at the first time, that data is the normal state.

In addition, you can do all the integration, and the ticketing becomes very easy, because command is a secure orchestration tool.

The configuration part was pretty easy, because if you're a agent, then you start getting the alert. That is the one thing. Then obviously, like any other SIEM tool, whether it is an install or a cloud-based architecture, the kind of alerts which you are getting. For example, if I have to suppress any specific alert in Splunk, then I have to be very well versed with the Splunk Processing Language, SPL, or I have to go to the CIM and then change.

In addition, Threat Stack has connectivity. A good example is Docker containers and AWS. This is one of the major things which makes it one of the prime tools for cloud security companies.

Firstly, it shoots back a lot of alerts. Secondly, there are some drawbacks which we have found. Sometimes, they say that the servers is down and up, but that thing is not coming up. This happens repeatedly.  Thirdly, the solution should have hash calculation. 

In addition, from a security point of view, they go to file level. That's pretty nice. But they are running completely onto AWS instances and Linux boxes most of the time, so a file can be modified, but what is happening on the process level? That should be the thing on which we should shoot alerts, not on basis of files.

Yes, there is an issue with stability. There is a search lag in GUI (graphical user interface). 

It is scalable. It deploys easily with curl and yum.

Installation is easy. But, there must be a good understanding of Linux. 

It is a cost-effective choice versus other solutions on the market. 

We considered McAfee and Trend Micro, but we chose this instead. 

An important feature of this solution is monitoring. Specifically, container monitoring.