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.

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 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.

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.

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.

The vendor seems really good. They respond well. We have monthly calls and they are actually a good company.

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.

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