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.

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.

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.

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 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 has a lot of different features that are quite useful.

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.

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.