We're customers and end-users. We use implementation partners associated with the product. I'd advise other companies considering the solution that it just comes down to the knowledge. There are people who have no the industry standards and then learn the product. It has similar fundamentals to a lot of different products, however, products have different UIs and different types of ways to build it up. You just need someone with knowledge and experience or someone who's going to be open to learning the product. Expertise really comes into it. A company can really get a lot out of customizing it. They just really need to learn the solution for the real possibilities to open up. Overall, I would rate the solution at an eight out of ten.
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."
Sr. Director Information and Security for PureCloud at Genesys Telecommunications Laboratories
Real User
2019-03-31T09:41:00Z
Mar 31, 2019
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.
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.
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.
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.
Learn what your peers think about Threat Stack Cloud Security Platform. Get advice and tips from experienced pros sharing their opinions. Updated: March 2024.
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.
Threat Stack Cloud Security Platform is a CWPP (Cloud Workload Protection Platform) that provides your organization with comprehensive security for modern applications and APIs. It is designed specifically for monitoring cloud environments, vulnerabilities, covering workloads, infrastructure, and compliance. The solution offers application infrastructure protection for all layers of your infrastructure stack and delivers the necessary observability for proactive and targeted remediation...
We're customers and end-users. We use implementation partners associated with the product. I'd advise other companies considering the solution that it just comes down to the knowledge. There are people who have no the industry standards and then learn the product. It has similar fundamentals to a lot of different products, however, products have different UIs and different types of ways to build it up. You just need someone with knowledge and experience or someone who's going to be open to learning the product. Expertise really comes into it. A company can really get a lot out of customizing it. They just really need to learn the solution for the real possibilities to open up. Overall, I would rate the solution at an eight out of ten.
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."
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.
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.
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.
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.
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.
An important feature of this solution is monitoring. Specifically, container monitoring.