What is our primary use case?
We are running the entire cloud base on AWS infrastructure. The major use case for this product is cloud misconfiguration because a lot of changes keep happening in our environment. There are multiple teams and multiple verticals within our organization. We have different verticals across different business units. They have their local IT infrastructure teams, and all these teams are making changes.
We have IT admins at multiple locations. There is a team of 10 to 12 members. It was a challenge to manage cloud security when they made changes, spun up new servers, or created new instances for new projects. Cloud misconfiguration was one of the major areas where we saw issues because things were not getting created as per the process or security protocol. When they are creating instances, they are not aware of the implications and the security incidents that may happen by keeping certain ports open. They might not be aware of the security issues that may come up. So, cloud misconfiguration was one of the main reasons why we opted for this product.
Another reason was to have a dashboard for the management and for the centralized team. We are a part of the centralized team that is taking care of the entire platform. It is very necessary for us to keep track of the changes and see if any P1 or critical security incidents are open. They are a risk to our organization's security. We wanted to have such visibility. Manually keeping track of those changes and open issues was very difficult for us.
How has it helped my organization?
It highlights critical or high-priority incidents. That is helpful. When we have a lot of issues on the dashboard, we can at least prioritize them based on the severity. We target critical incidents first and then move to the high-priority incidents. We still have medium and low-priority incidents on the dashboard. We require some amount of time to fix them. From a reporting perspective, it helps us to prioritize accordingly. We know that at least from a high-impact point of view, we are secure.
We do generic vulnerability scanning whenever there are any new changes or we are building any new applications. We keep the generic vulnerability scanning on whenever any new instances are created, and we run the scan once a week for already created instances.
We have not explored evidence-based reporting much. It is a good feature, but we mostly look at the priority of the incidents. We fix them based on the criticality. The description of the issues and the categorization make it easy to utilize the reports.
It has affected our risk posture. All the critical incidents and high-priority issues have been resolved. We are in a better place now in terms of risk posture. The medium-severity issues still need to be fixed, but earlier, we used to have critical incidents as well. We did not have any visibility into those things. We are now quite confident that we do not have any major security issues. We keep running the scan every week. It helps us to detect any new changes or vulnerabilities in our environment.
We could see its benefits immediately in terms of visibility. Previously, we did not have any visibility into where we were in terms of the security landscape. That benefit was immediate, and then we started fixing the problems and reduced critical issues and high-priority issues. We became confident in our security, and we were able to secure the environment wherever we had an incident. Its benefits were immediate from a visibility point of view, and then it took two to three months to have a direct impact in terms of security.
Singularity Cloud Native Security helped us to reduce false positives. We also have a managed service provider. We took their help to reduce false alarms and other issues. It also helped us to implement some of the best practices while creating any instances or making any changes to any particular instances. We created best practices and standard operating procedures for the infrastructure team. They follow the standard operating procedures while making any changes or creating any instances. We are seeing a drop in the number of issues compared to two or three years ago.
Our remediation time is reduced. Initially, it took some time to identify the remediation steps and what had to be done to fix the problems, but now we know what needs to be done. From a prevention point of view, we now know what we should not do. That has helped with changes that we keep on doing in the environment.
What is most valuable?
Singularity Cloud Native Security provides us with a platform to scan instances when they are getting created, and the dashboard helps us to identify the critical issues. We created a road map and prioritized the issues based on the criticality of the problem. We have reduced P1s. We have resolved any critical incidents that came up in the dashboard. We still get high-priority incidents, and we keep on prioritizing and fixing them. That is because we have visibility into the open issues that we have. Management is also happy. They are aware of the things that are coming up on the dashboard. They are aware of the impact and the risk. We did not have this visibility previously. All the teams that are a part of IT are aware of the importance of it. It has been included as part of our software development cycle.
It is very easy to use. The user interface or the dashboard is quite simple. It clearly shows you the type of issues that are there. It also breaks down and groups them into the types of issues. If I have 100 issues on the dashboard, it categorizes them. Out of these 100 issues, 50 of them might be related to the same category. If I choose one of the high-priority incidents and fix them, all 50 issues might get fixed. This way, it is a bit easier for us to target specific use cases and resolve a lot of underlying problems. The descriptions are helpful. It gives us information about how to resolve a particular problem. It is easier when the tool itself tells you what you have to do to fix an issue. You can then research more and get it done. It is quite simple. Even the leaders who are not very technical can understand what is the impact and what is causing the problem.
What needs improvement?
They can provide some kind of alert when a new type of risk is there. There can be a specific type of alert showing that a new type of risk has been identified.
We use Jira for pushing any changes. If any kind of integration is possible between Jira and the Singularity Cloud Native Security dashboard, it will be easier for us to track. Before approving in Jira, I can ensure that any issues in Singularity Cloud Native Security are closed. Such an integration will be helpful.
Its pricing model is a little bit inflexible. Different organizations have different structures. We have multiple business units. Based on the different verticals, we have to create different subscriptions for them. If I create a new subscription and add it to Singularity Cloud Native Security, as per the current licensing model, I have to pay more for that. It should not be like that. It should be based on the number of servers. This kind of flexibility would help customers like us.
For how long have I used the solution?
It has been close to two years since we have been using this solution. Prior to this, we were working with CrowdStrike, and then we migrated to SentinelOne two years back.
What do I think about the stability of the solution?
I have not seen any issue with Singularity Cloud Native Security.
What do I think about the scalability of the solution?
If any slowness is there, we will probably wait and run it after half an hour or one hour. Nothing major has been highlighted to me or has been a blocker as such. The pricing model is the only thing that would be a concern.
How are customer service and support?
We take help from our managed service provider. If we have to fix any particular problem that we are not aware of or do not have the expertise for, we get help from the managed service provider. They have a service team with experts. They get it done for us.
Which solution did I use previously and why did I switch?
We did not directly use any other solution. We have a managed service provider. We have taken their help, but it was more of a tool that they used at their end, and then they shared a report with us. Based on that report, we took action. It was not a regular thing that we used to do. Once in a quarter, we would probably allow them to scan and send us a report. Based on that, we used to take action. That was the process that we used to follow earlier.
How was the initial setup?
Its implementation was a little bit difficult because it was a new tool that we were using. It takes time to understand the issues, specifically in terms of what has to be done to fix them. Aligning all the teams was a little bit difficult for the initial two to three months, but once we understood the product and what needed to be done for the issues that were getting highlighted in the dashboard, it was easy.
Initially, we had to do a lot of sessions to bridge the gap. That was because this initiative was taken by the Cloud Security team and the DevOps team. We needed a lot of patience to collaborate with the engineering or development team. A lot of the issues required help from the engineering team in terms of making changes at the core level as well. It took one or two months of time to do sessions with the developers and create SOP within the development life cycle itself. Overall, the support from the leadership was quite good. All the leaders agreed that this is a very important change that we are bringing into the organization, and it will be an ongoing thing that we need to follow. We have also added it as part of the SDLC. We use Jira to manage changes and defects. We have added security as one of the flags over there. Someone from the InfoSec team has to give a sign-off for any changes that are happening. If a project is going live, he has to check any open issues in Singularity Cloud Native Security. He has to give a sign-off before the project goes live. That is one of the changes that we have pushed in terms of the product life cycle itself, and that has helped to align different things. Unless they get a sign-off from the InfoSec team, it cannot be deployed. Everyone knows the process now. It is a part of the cycle.
It took at least 45 days to deploy and utilize all the features. We did not do it in one go. We did it phase-wise. We opted for one subscription, and then we slowly deployed it across other subscriptions.
It does not require any maintenance from our side. We have a managed service provider, and they are keeping track of it. There is no additional maintenance as such. We just have to keep track of things. It is more of a process adherence and making sure that we keep a check before we push anything into production.
What's my experience with pricing, setup cost, and licensing?
I am personally not taking care of the pricing part, but when we moved from CrowdStrike to Singularity Cloud Native Security, there were some savings. The price of CrowdStrike was quite high. Compared to that, the price of Singularity Cloud Native Security was low.
Singularity Cloud Native Security is charging based on the subscription model. If I want to add an AWS subscription, I need to pay more. It should not be based on subscription. It should be based on the number of servers that I am scanning. There should not be an extra charge for adding a subscription, and the pricing should be based on the number of servers that I am scanning.
What other advice do I have?
We are not using Singularity Cloud Native Security's Offensive Security Engine. We used the Infrastructure as Code (IaC) Scanning initially. When the demo was given, we had to use that scanning, but it is not something that we keep running on a regular basis.
Overall, I would rate it a nine out of ten. I am quite happy with the service and the value that it provides. The one point that I am not giving is because of the pricing model. If it had a more flexible pricing model, I would rate it a ten out of ten.
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.