We have multiple rules set up on SentinelOne Singularity Cloud Security for things that we want to monitor. We have set up something for restricted access for SSH, and then we have access to the EC2 instances. If any of the rules are broken or if there is a bad actor, we get notified quickly. It also helps with the audit and keeping the infrastructure clean.
SentinelOne Singularity Cloud Security includes proof of exploitability in its evidence-based reporting. This is quite important for us because we are a security-based company. We want to tag each and every alert correctly. We also need to provide RCA to the customers. SentinelOne Singularity Cloud Security forms a very good basic layer for things that are happening in the infrastructure. The reports that it gives are also nice. It gives us information about the impact and other things. It helps us.
Its setup is good. It also depends on how finely you want to set it up. It depends on the rules you set, the thresholds you set, and how quickly you act on things. We did not want SentinelOne Singularity Cloud Security to act on things, so we went for a basic setup without any auto-remediation. We act on the issues. It provides us with a basic layer of security.
Previously, we used to find issues from the AWS console and the AWS logs, but because we had multiple AWS accounts, finding out the issues was a bit of a pain point for us. We had to go inside 30 to 40 AWS accounts to find out the capabilities. We had to write our own automation scripts to find the full logs. We wanted a solution that gave us a centralized place to put all the issues that we were facing based on security concerns. With SentinelOne Singularity Cloud Security, we found a centralized solution. It was easy for us to get the data of 30 to 40 clusters in a single dashboard. It was pretty nice to have that. The UI seems a bit confusing initially, but once you start using it, it becomes more intuitive.
There is a team that is working on setting it up on ISE. So far, with just a vanilla setup, it is doing its job, and we are happy with it.
There are a few false positives, but we want them to be there. We do not want to miss out on something. We want everything to be monitored. It does not matter to us if it is a false positive. At the end of the day, the cost that we would pay by ignoring a true positive thinking it is a false positive would be much higher than going through false positives and marking them as false positives.
For every module and everything that we do on our AWS clusters, we evaluate the risk individually, and then SentinelOne Singularity Cloud Security forms an extra layer of security on top of the personal checks that we do. It is like a shield for us. It helps us a lot.
SentinelOne Singularity Cloud Security has reduced the mean time to detect issues by a lot. Earlier, it was a very manual process to detect errors. There was not a single place where we could look into all the alerts. They were all scattered. SentinelOne Singularity Cloud Security unified that. With SentinelOne Singularity Cloud Security, once the alert is detected, we can just look into it directly. We can go into a specific cluster, resolve the issues, and mark it as resolved. There is a 45% to 50% reduction in the mean time to detect.
Our mean time to remediate remains the same because we have manual remediation. There is no change in that. The main issue for us was to be able to detect issues, and SentinelOne Singularity Cloud Security solved that for us, but because remediation is taken care of by us manually, the mean time to remediate remains the same.
SentinelOne Singularity Cloud Security is continuously monitored by the customer success engineering team and the security team. These people contact the infrastructure team. The application team is not involved because we mostly monitor the infrastructure side. That is the AWS side. It helps us with better collaboration. When the time zones change, we do not have to give a lot of context or change information across different time zones to different people. They can go into the console, see the issue, and continue to work on it.
Earlier, if there was a security issue, it had to be handed over to people in different time zones. Because we are a global company, we have on-calls and other things. Earlier, it used to be a big process. We had to write down the whole documentation of what happened, where we were seeing the issue, and whether it was resolved or not. We had to provide the complete information on that single issue. Things are simpler now because people can just log into it and see what is in the pending state and which security vulnerabilities we are still facing. A person in a different time zone can just log into the SentinelOne Singularity Cloud Security console and start remediating the issue.