SentinelOne Singularity Cloud Security Reviews

Cloud Native Security is a cloud posture management solution. Initially, it focused on helping us understand and assess our compliance posture and cloud configuration for workloads, etc. 

There are three key use cases for Cloud Native Security:

1. Continuous Configuration Monitoring: This ensures 24/7 oversight of configurations and identifies any issues as they arise.
2. Asset Visibility: Gain immediate visibility of all cloud assets upon deployment and ensure they are properly tracked within the system.
3. Container Security: Assess vulnerabilities in Docker clusters and other containerized environments based on compliance requirements.

I have used Prisma Cloud extensively at several organizations. We have also used Wiz and Cloud Native Security. Cloud Native Security is particularly easy to use because it requires no configuration. All we need to do is create an API key that connects to our cloud account, and it will automatically start identifying all the workloads and accounts associated with our master account. We can see them all listed on our screen. Cloud Native Security does not require any configuration beyond selecting what we want to see on the screen. On the other hand, Prisma Cloud which I used until about a year and a half ago was superior in some ways. However, the amount of data it generated was very high, and it produced a lot of alerts and events. This required trained personnel who understood our workloads and specific cloud environments to manage it effectively. Cloud Native Security is a low-maintenance product. It is pre-configured and requires minimal manual setup, making it ideal for small to medium-sized teams that don't have dedicated resources to manage individual security products.

Like any other product, every incident has its own unique characteristics. Incidents are typically classified into categories of critical, high, medium, and low. This classification is based on the nature of the vulnerability, the ease of exploitation including whether authentication is required, and the potential impact. There are many similarities to other scoring systems when you consider the underlying factors and the overall environment. This system resonates with me because it considers multiple factors beyond just the Common Vulnerability Scoring System. For example, it takes into account features or passphrases that are displayed on the screen or found on devices, and how that data is stored.
The current system incorporates some internal analysis, but it's minimal. While the overall classification is likely appropriate, the remediation guidance could be enhanced. Ideally, for each vulnerability, there should be clear instructions on how to fix it. However, some vulnerabilities might be relevant to an organization's specific use case. For example, a public IP address being accepted by an SQL server on Azure might be flagged as a vulnerability, but it could be a legitimate configuration for an organization that has a specific database configuration requiring access from multiple locations.

Cloud Native Security operates entirely agentless. Using just the API key on the master tenant provides complete coverage, regardless of the cloud platform we're using. We avoid agent-based solutions for a simpler and more efficient approach.

While evidence of exploitability in Cloud Native Security's reporting might not be crucial, it would be beneficial. If a vulnerability is actively exploited, we need a comprehensive solution to analyze the information and enhance our monitoring. However, that's just our perspective. In terms of Cloud Native Security's scanning ability, I find it limited. It displays the essentials, and the module essentially fills the attack map. However, it doesn't explicitly consider the exploitability index. Despite this, the existing exploitability scoring seems adequate. If a vulnerability can be exploited on our network which is simply a local network with zero authentication required, the complexity is factored in, and the vulnerability is classified as high, medium, or critical.

We leverage the offensive security engine to identify potential zero-day vulnerabilities that might be relevant to our workloads. Additionally, it helps us assess exposed configurations or misconfigurations that could be exploited by these vulnerabilities. While this engine is a valuable secondary source of data for improvement, it doesn't replace the independent solution we used previously. We primarily rely on that solution for information specific to our environment.

There are two main approaches to IaC scanning. One involves internal and Docker security modules. These modules analyze internal container images to identify vulnerabilities. For additional scanning, we leverage other products. We use Tenable and integrate it with CI/CD tools. This allows us to scan code dynamically and analyze traffic on a one-time basis. Additionally, PingSage assists in gathering data for IaC scanning.

Cloud Native Security significantly reduces the number of false positives we encounter. Unlike some other tools, it generates very few alerts that are ultimately unimportant low noise. I've rarely seen false positives from Cloud Native Security. While some Cloud Native Security alerts might be legitimate concerns, we can also suppress them if they're not relevant to our standard operations. This allows us to configure our cloud environment to focus on the most critical alerts.

Cloud Native Security has had a positive impact on our risk posture. As our only CSPM solution, it helps us with asset discovery, critical asset monitoring, and configuration issue detection and remediation.

Cloud Native Security has significantly reduced our average time to detection. Detection is almost always achieved in a single instance. We've confirmed this through multiple tests. The longest detection time we've encountered is around three to four hours. This extended timeframe occurs because the scan isn't running continuously. Instead, it operates at specific intervals, periodically examining our infrastructure and performing analysis. Consequently, the detection speed depends on when the misconfiguration happened relative to the next scheduled scan.

Our remediation process is entirely internal. Servers deliver the fix based on the severity assigned by Cloud Native Security, which is directly related to the vulnerabilities found. We then use our internal analysis to consider the environmental configuration. If the vulnerability is a zero-day in the user acceptance environment, we delay remediation until a later time. However, if it's found in the production environment, we address it immediately. We also prioritize remediation based on importance, so we see alerts related to production or pre-production instances first. The remaining vulnerabilities are addressed afterward.

Cloud Native Security has had a positive impact on our engineering functions, such as DevOps and the cloud infrastructure network team. It fosters a collaborative environment where teams can address alerts independently. This empowers engineers to take ownership and resolve issues promptly. DevOps is our primary user group, and Cloud Native Security helps them manage infrastructure, network, and CI/CD deployments efficiently.

Collaboration helps save time, particularly in engineering tasks related to infrastructure and technical deployment, rather than in development itself.

We use it for a couple of use cases. The biggest one we use it for is to protect our AWS environment, and it does a couple of functions for us and our whole development. It scans all the code in our GitLab or our code repository and looks for any hard-coded passwords or keys or any insecurities. It checks if we have any old deprecated components within our software and points that out.

There are a couple of gates that we can set up. When we are pushing the code out of the repos into AWS, it finds any high-severity vulnerability. This is configurable, but we have critical, high, and medium severities. If it finds any, it blocks the push and puts some notes in for the developers to go in to remediate the issue before they can push the code into AWS. Let us assume the code is good in GitLab and gets over to AWS. It then does a couple of things on the AWS side. It looks at the overall infrastructure and how things are configured. There may be things in AWS that are misconfigured or old components that were manually built or deployed without going to GitLab. It points them out.

I have been very happy with the evidence-based reporting. It is not just theoretical. It scans the code or looks at the AWS environment and pulls back the details that tell us that this is a vulnerability. We have a good understanding of why it is a highly-rated vulnerability. It makes it much easier to prioritize and then go through and remediate the issue.

Agentless vulnerability scanning has been very good. It pulls back quite a bit of information that is actionable by our team.

Singularity Cloud Security includes proof of exploitability in its evidence-based reporting. That is critically important because especially in large environments, when you run scans or use the vulnerability scanning tool, you might be inundated with results. It takes a long time for analysts to go back through and validate whether it is a true positive or a false positive. Singularity Cloud Security can eliminate a lot of false positives or almost all of them, and we can focus on something that is a true issue, as opposed to wasting our time and resources.

The Offensive Security Engine is doing the attack path management. That is one of the most critical features to us because it tells us that we have this misconfiguration here, or we may have a secret or some vulnerability here. It tells us about the impact and how an attacker could exploit that to gain persistence in our environment and install data. We have a true impact of why this is important and why we need to fix it. With scanners like Rapid, Qualys, and others, we get the credentials and we get a scan, but then we spend an inordinate amount of time looking through reports and trying to figure out:

• Where do we spend our time?
• What do we prioritize?
• What is remediated?
• What is it that we can remediate?
• What is it that we can take action on and make an improvement in the environment?

It is very frustrating when you are spending hours only to run down something and realize it is a false positive, and there is nothing you can do to make a positive impact. Eliminating all those false positives really helps us.

We have had very good luck with the IaC. For us, it is hugely valuable because we can catch things very early in the process before they get promoted into production. In case something flips through or escapes, it still helps you to find it.

We started seeing its benefits literally the day after deployment. The only reason I say the day after is because we ended up working on it kind of late in the afternoon. We got things set up, and it took a few hours for results to start populating, but its benefits were very apparent when we started looking through the reports and dashboards.

Singularity Cloud Security significantly helped reduce the number of false positives we deal with. The biggest aspect for us is allowing the security and development teams and DevOps to be much more efficient. As opposed to spending 80 hours going through some big reports, we are able to cut that down to a fraction of the time and make a positive impact on the environment. We are not chasing a bunch of dead ends.

It has made a great impact on the risk posture. We are also able to look at the trends over time in terms of where we started and what we remediated. You can see the environment getting more secure as we keep knocking down vulnerabilities.

Our mean time to detect is much faster. It is a much lower number there. There has been a significant change in the number of vulnerabilities remediated or per hour of investment from the engineering and security teams. By implementing this tool, we are able to do a lot more with the same team size and remediate things much faster than before.

It has made it much easier for these disparate teams to have the conversation in terms of what needs to be prioritized and fixed, and then it has given a lot more information. It eliminates some of the he said, she said, or some of the frustration that can happen between different teams because one team is looking at a tool they are familiar with and the other team has a different tool. Historically, there were some disagreements in terms of what issues exist in the environment and where we should spend our time in terms of trying to make improvements and remediate.

My company does utility energy disaggregation. We use PingSafe for vulnerability management and to limit our exposure to attacks. PingSafe scans our AWS cloud environment and provides detailed analysis. It can identify enabled ports or anything that isn't completely integrated with our security. PingSafe gives us the details, and we only need to follow their instructions to ensure the vulnerabilities are fixed.

My company handles a lot of customer data for US and European clients. GDPR and SOC 2 standards require that we are almost completely free of vulnerabilities. We also have a PingSafe safety score and report that we can provide to our customers. PingSafe is integrated with our AWS environment, and it monitors a few customer-critical applications. Two people at my company use PingSafe. I am on the IT security side, and another person from the platform security side uses it. 

Since implementing PingSafe, we've discovered many vulnerabilities and security issues in our environment. We've fixed those so our data will not be leaked or otherwise compromised. Our priority is protecting customer data, and if we have any issues with the data, it won't be good for business.

PingSafe has reduced the false positive rate by around 40 or 50 percent. It has improved our risk posture. We're more secure now. The solution has reduced our mean detection time by about 70 to 80 percent. It does a lot of the work for us. The mean time to remediate has nearly been cut in half. 

The solution's compliance features help us remain SOC 2 compliant. Our third-party auditors ask us to provide vulnerability reports and fix all vulnerabilities we have detected. PingSafe gives us all this information our SOC 2 auditors need.

We primarily use PingSafe for cloud security posture management, but the solution also provides other capabilities, like infrastructure-as-code scanning. It identifies hard-coded secrets in the source code and covers Kubernetes security. About 25 members of the security and DevOps teams use the solution. 

We have integrated all of PingSafe's CWPP, CSPM, application security, and container scanning features into Jira. It's more of a vulnerability management tool for us. All the issues PingSafe identifies flow into Jira, and we have several dashboards that provide an overview of open security issues.

We were using open-source tools. Collecting and collating the results from each tool into one dashboard was so difficult, and PingSafe solved this problem. PingSafe gives us greater insight into our cloud security posture. For example, it tells us if buckets are public or ports are open. It can also tell you if a repository is going public or if any hard-coded secrets are pushed into the source code. PingSafe will notify you when permissive users are created in the GCP environment. It offers a better UI and improved visibility compared to our open-source tools. 

PingSafe helped us identify when a developer made our repository public. It identified the issue in minutes. The repository had a few hard-coded secrets that would've caused problems for us because anybody on the internet could access those keys and exploit the systems. PingSafe caught the issue quickly. The same goes for public buckets. One of our DevOps engineers made a bucket public, and it had a lot of files in it. PingSafe was on top of it. The solution has an automated workflow that automatically blocks this kind of misconfiguration.

It has helped us reduce the number of false positives. Sometimes, you get too many false positives because the tool doesn't have enough context. For example, let's say we have a bucket that we want to be public, and CSPM tools will identify the public bucket as a vulnerability. We can make exceptions or mute the alert. PingSafe provides many ways in the UI to mark false positives or mute those tickets so that I don't get them repeatedly. I can also create tags for every issue and put all of the false positives under one tag.

The detection is almost instant. We get Slack or email notifications immediately when issues are detected, reducing our mean time to detect by more than 30 percent. Our remediation time has also improved by about 30 percent or more. We are in the fintech space, so we remedy vulnerabilities right away. The faster our detection, the faster our response. Both have significantly improved. 

PingSafe facilitates collaboration between the application security, cloud, and DevOps teams. These three teams use it, and the security team manages it. When PingSafe flags vulnerabilities, they are forwarded to DevOps for remediation. Previously, we needed to identify and report the issues, but there would be lapses in communication. Now it's a central dashboard. Anybody can look at the dashboard to see the open issues, what needs to be explored, and how the problems can be remediated. It's self-explanatory. Teams can understand the issues and descriptions, and they directly act on the recommendations.

As a frequently audited company, we value PingSafe's compliance monitoring features. They give us a report with a compliance score for how well we meet certain regulatory standards, like HIPAA. We can show our compliance as a percentage. It's also a way to show that we are serious about security.

The company purchased PingSafe primarily for container security and IoC scanning. We also were looking into image scanning for Docker components. Now, we have enabled secret scanning and the Cisco pipeline as well. 

We are mostly dealing with code-level security issues the organization might have. There are issues in TerraForm and whatever else we see in our DevOps pipeline. 

PingSafe has improved the organization's Docker container security, and we can mitigate many of the issues to avoid serious vulnerabilities or attacks. We start to see these benefits within 2 or 3 months of deployment. The tool took almost a month to learn the structure of our organization and environment. After that, it started detecting issues and vulnerabilities. 

We don't get many false positives because we eliminated many of them in the early stages. PingSafe can mark detections as false positives, so they won't appear in the future. 

PingSafe has reduced our detection time. Before implementing PingSafe, it took us around 7 or 8 hours to determine whether an issue was inside our organization. Now that we have deployed PingSafe, we have an agent list running on our Docker containers, and PingSafe is identifying the issues inside the Docker containers. When it scans periodically, we can detect the issues within 2 or 3 seconds. It has reduced 7 hours of work to a few seconds. 

While it hasn't reduced our remediation time on mid-level or low-level issues, it has drastically improved our remediation time for critical Docker issues and high-priority problems in our environment. We can handle them before they make it into production. 

PingSafe has improved collaboration between our developers and security teams. The tool has a feature where we can send issues to developers, but it requires them to reply with recommendations.

As a financial institution, we rely on PingSafe as our single source of truth for both CSVM and CWPP data. PingSafe provides us with essential security benchmarks, including those for Kubernetes deployments and CSVMs. It also allows us to monitor our overall cloud security posture and identify vulnerabilities for remediation. PingSafe serves as a centralized platform for all our cloud security metrics.

We rely on PingSafe for all our reporting needs. It serves as a comprehensive tool for vulnerability management, ISC management, and reporting on hard-coded secrets. Additionally, it functions as a source for vulnerability identification.

The security engine provides a large vulnerability database. While it's not exhaustive, it's a valuable resource due to its significant size and well-organized data. This database allows for effective security management and vulnerability identification.

I would rate PingSafe's meant time to remediation abilities a 10 out of 10.

PingSafe helps the collaboration between our cloud security app developers and AppSec team.

We use Singularity Cloud Workload Security for our production and build workloads.

We implemented the solution to simplify the deployment of forensic tools, including EDR, into our cloud infrastructure, where it may be difficult to install an agent.

We have a hybrid deployment, with an estimated 8,000 to 70,000 cloud workloads. We serve a customer base of nearly one billion people, including 700 million current EA subscribers. Handling this workload is no small feat. The estimate is so broad because we do not own or control every AWS, Azure, or GCP account; studios use this infrastructure without our help. We are still in the discovery phase of trying to determine the exact number of workloads. There are thousands of Kubernetes clusters.

Singularity Cloud Workload Security's real-time threat detection capabilities are good. We recompeted SentinelOne against fifteen or twenty different AV vendors over the course of 2018 and 2019 and found SentinelOne to be superior in virtually every possible way.

Forensic capabilities are now excellent. When we started, we had a contractual agreement with SentinelOne to improve deep visibility to match our current toolset, Carbon Black Response. Over the course of two years, they delivered everything we could get from Carbon Black and even more.

The visibility of workload telemetry is excellent, and the hunting capabilities are second to none.

When no human intervention is required Singularity Cloud Workload Security detects and remediates nearly instantaneously.

Our MTTD is sub 30 days.

Our MTTR is seven days after detection for most instances.

The interoperability with third-party solutions is great.

We use PingSafe to identify threats and vulnerabilities in our AWS accounts and the compute resources that are hosted on those cloud accounts.

We implemented PingSafe to address network-related issues, such as communication between individual components (part-to-part or node communication). PingSafe's Graph Explorer feature also helped us understand the overall network landscape, including the attack surface. This feature allows us to discover and explore various components within our AWS environment. In essence, PingSafe helped us identify how different networks connect and how microservices within our system interact with each other.

We've implemented PingSafe across all our core companies, including acquisitions. Previously, managing separate AWS accounts for each company with dedicated DevOps and security teams was a significant challenge. PingSafe helped us consolidate these accounts into a single platform, simplifying the process. Now, we can easily track key security metrics. For instance, PingSafe provides frequent alerts for critical events such as publicly exposed instances or security groups with significant traffic changes from any source. Monitoring these elements across multiple accounts and security groups was previously difficult without a centralized platform. PingSafe has been instrumental in streamlining this process.

We recently made some changes to our information systems. PingSafe helped identify instances that were inadvertently made public. This identification is important for compliance purposes, as it allows us to track how well these public instances adhere to regulatory frameworks.

PingSafe's compliance monitoring capabilities have provided us with some benefits, particularly in understanding our overall security posture. However, it's important to note that PingSafe only monitors our cloud infrastructure. There might be internal deployments with compensating controls that address missing controls identified by PingSafe (e.g., control X is missing but mitigated by internal control Y). These internal controls wouldn't be visible to PingSafe. Therefore, while PingSafe provides a valuable starting point at the surface level, manual review is necessary to ensure complete compliance coverage.

PingSafe is easy to navigate. Its menus are straightforward and intuitive, making the overall user experience smooth.

One of the key benefits of PingSafe's evidence-based reporting is its proof of exploitability. This feature allows us to prioritize vulnerabilities that have been demonstrably compromised and take immediate action to mitigate the risks.

The offensive security engine feature constantly scans and lets us know if any vulnerabilities in our environment can be exploited. While the offensive security engine for verifying exploit paths and prioritizing breach control is valuable, it lacks context awareness. For instance, it might flag something we intentionally made public, like a new website for an upcoming event. In those cases, we can safely ignore the alert. Overall, the engine is a useful tool. We extract the information it provides and prioritize it. A dedicated team reviews the alerts and, if necessary, escalates them to our DevOps team for further action.

By centralizing cloud infrastructure monitoring with PingSafe, our security team's productivity, and MTTR have been significantly improved.

Over time PingSafe has reduced the number of false positives by 40 percent.

PingSafe has significantly improved our organization's risk posture. Since implementing it, we've been able to assess the risk associated with recently discovered CVEs much faster than before. This efficiency is due to PingSafe's proactive identification and scanning capabilities. Now, we start each day with a clear summary of potential risks, allowing us to prioritize effectively.

PingSafe has reduced our mean time to detection by 90 percent. This is because it scans every day and sends us real-time email alerts, allowing us to take immediate action.

PingSafe has reduced our mean time to remediation by 40 percent.

We have a dedicated channel where we collaborate with PingSafe and our internal teams.

The collaboration helped save our engineering time by 60 percent.

PingSafe's user interface and ease of use have had a positive impact on our security operations. For example, we recently needed a list of assets deployed in a specific GN in a cloud account for a particular incident. We went straight to PingSafe and were able to quickly obtain the assets along with a map of the security groups linked to them. The UI's simplicity helped us save significant time by eliminating the need to search for information manually.